net.pipe vs. net.tcp vs. http Bindings
I’m new to WCF and would like to know the differences/advantages/limitations/etc of each of the following bindings:
Supporting scenarios on when to use each binding and other examples would be appreciated.
3 Answers 3
While not great for providing specific usage examples, here is a link from MSDN which lists all the features for the bindings.
Here is a decent flow chart that can help choosing between them as well.
Here is a good overall article I’ve used in the past.
net.pipe, fast and secure because your web service is not accessible from the network (typically, you will use net.pipe to interact with a windows service easily).
http, you will use it for interoperability reason, if your web service is not over HTTP, silverlight or flash cannot use it (because the browser filter non-http packets, as a firewall does).
net.tcp, is a bit faster because your soap message is not wrapped inside a HTTP request, but you cannot invoke your webservice with a RIA technology, and some firewall will drop your message.
Windows Communication Foundation (WCF) is a framework for building services that process XML messages. WCF allows you to transmit messages using different transport protocols (such as HTTP, TCP, and MSMQ) and using different XML representations (such as text, binary, or MTOM, which is commonly referred to as the message encoding in WCF.
If you want to host many WCF Services on one machine and want them to use shared memory for their communication, use a named pipe=>net.pipe, and then use tcp for the communication to WCF Services on different machines.
Configuration of nettcp binding focuses on creating a channel stack that will perform better in Windows environments, giving you a great option for replacing your various COM+ and .NET remoting investments.
BasicHttpBinding was designed for scenarios where interoperability is of utmost importance. As a result, BasicHttpBinding uses HTTP for the transport and text for the message encoding.
net.pipe против net.tcp против привязок http
Я новичок в WCF и хотел бы знать различия / преимущества / ограничения / и т. Д. Каждой из следующих привязок:
Было бы полезно поддержать сценарии того, когда использовать каждую привязку и другие примеры.
3 ответы
Хотя это не очень удобно для предоставления конкретных примеров использования, вот ссылка из MSDN, в которой перечислены все функции для привязок.
Вот хорошая блок-схема, которая также может помочь выбрать между ними.
Вот хорошая общая статья, которую я использовал в прошлом.
ответ дан 03 апр.
Мишель Леру Бустаманте провела хорошее сравнение всех различных привязок с примерами в своей книге: Изучение WCF — Арман Биматов
@JoeDoyle В то время как этот ответ пытается ответить на вопрос, не могли бы вы улучшить свой ответ, добавив в свой ответ какие-либо соответствующие выдержки из ссылок, на которые есть ссылки? Это будет полезно для будущих посетителей, поскольку им не нужно будет переходить по ссылкам и, что наиболее важно, поможет защитить ваш ответ от мертвых ссылок. — Кермит
Мне это нравится, мне это нравится, мне просто нравится эта блок-схема! Действительно удивительным! — Адитья Бокаде
net.pipe, быстрый и безопасный, потому что ваш веб-сервис недоступен из сети (обычно вы будете использовать net.pipe для простого взаимодействия со службой Windows).
http, вы будете использовать его по причине совместимости, если ваш веб-сервис не работает через HTTP, silverlight или flash не могут его использовать (потому что браузер фильтрует пакеты, отличные от http, как это делает брандмауэр).
net.tcp, работает немного быстрее, потому что ваше мыльное сообщение не заключено в HTTP-запрос, но вы не можете вызвать свой веб-сервис с помощью технологии RIA, и некоторые брандмауэры сбросят ваше сообщение.
ответ дан 19 апр.
Windows Communication Foundation (WCF) — это платформа для создания служб, обрабатывающих сообщения XML. WCF позволяет передавать сообщения с использованием различных транспортных протоколов (таких как HTTP, TCP и MSMQ) и с использованием различных представлений XML (например, текстовых, двоичных или MTOM, которые обычно называют кодировкой сообщений в WCF.
Если вы хотите разместить много служб WCF на одном компьютере и хотите, чтобы они использовали общую память для обмена данными, используйте именованный канал => net.pipe, а затем используйте tcp для связи со службами WCF на разных компьютерах.
Конфигурация привязки nettcp фокусируется на создании стека каналов, который будет лучше работать в средах Windows, что дает вам отличный вариант для замены ваших различных инвестиций в удаленное взаимодействие COM + и .NET.
BasicHttpBinding был разработан для сценариев, в которых взаимодействие имеет первостепенное значение. В результате BasicHttpBinding использует HTTP для транспорта и текст для кодировки сообщения.
ответ дан 19 апр.
WCF не требует сообщений XML. Например, сообщения могут быть закодированы в виде обычного текста или двоичного кода — Jbatista
MTOM — это не сообщение, содержащееся в WCF. Это оптимизация сообщений SOAP для предотвращения преобразования двоичных данных в Base64. Это BasicHttpBinding, использующий SOAP (XML). — Ооооги
Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками .net wcf wcf-binding or задайте свой вопрос.
netpipe(1) — Linux man page
See the TESTING sections below for a more complete description of how to run NetPIPE in each environment. The OPTIONS section describes the general options available for all modules. See the README file from the tar-ball at http://www.scl.ameslab.gov/Projects/NetPIPE/ for documentation on the InfiniBand, GM, SHMEM, LAPI, and memcpy modules.
Description
NetPIPE uses a simple series of ping-pong tests over a range of message sizes to provide a complete measure of the performance of a network. It bounces messages of increasing size between two processes, whether across a network or within an SMP system. Message sizes are chosen at regular intervals, and with slight perturbations, to provide a complete evaluation of the communication system. Each data point involves many ping-pong tests to provide an accurate timing. Latencies are calculated by dividing the round trip time in half for small messages ( less than 64 Bytes ).
The communication time for small messages is dominated by the overhead in the communication layers, meaning that the transmission is latency bound. For larger messages, the communication rate becomes bandwidth limited by some component in the communication subsystem (PCI bus, network card link, network switch).
These measurements can be done at the message-passing layer (MPI, MPI-2, and PVM) or at the native communications layers that that run upon (TCP/IP, GM for Myrinet cards, InfiniBand, SHMEM for the Cray T3E systems, and LAPI for IBM SP systems). Recent work is being aimed at measuring some internal system properties such as the memcpy module that measures the internal memory copy rates, or a disk module under development that measures the performance to various I/O devices.
Some uses for NetPIPE include: Comparing the latency and maximum throughput of various network cards.
Comparing the performance between different types of networks.
Looking for inefficiencies in the message-passing layer by comparing it to the native communication layer.
Optimizing the message-passing layer and tune OS and driver parameters for optimal performance of the communication subsystem. NetPIPE is provided with many modules allowing it to interface with a wide variety of communication layers. It is fairly easy to write new interfaces for other reliable protocols by using the existing modules as examples.
Testing Tcp
NPtcp can now be launched in two ways, by manually starting NPtcp on both systems or by using a nplaunch script. To manually start NPtcp, the NetPIPE receiver must be started first on the remote system using the command:
then the primary transmitter is started on the local system with the command
NPtcp -h receiver_hostname [options]
Any options used must be the same on both sides.
The nplaunch script uses ssh to launch the remote receiver before starting the local transmitter. To use rsh, simply change the nplaunch script.
nplaunch NPtcp -h receiver_hostname [options]
The -b TCP_buffer_sizes option sets the TCP socket buffer size, which can greatly influence the maximum throughput on some systems. A throughput graph that flattens out suddenly may be a sign of the performance being limited by the socket buffer sizes.
TESTING MPI and MPI-2
Use of the MPI interface for NetPIPE depends on the MPI implementation being used. All will require the number of processes to be specified, usually with a -np 2 argument. Clusters environments may require a list of the hosts being used, either during initialization of MPI (during lamboot for LAM-MPI) or when each job is run (using a -machinefile argument for MPICH). For LAM-MPI, for example, put the list of hosts in hostlist then boot LAM and run NetPIPE using:
lamboot -v -b hostlist
mpirun -np 2 NPmpi [NetPIPE options]
For MPICH use a command like:
mpirun -machinefile hostlist -np 2 NPmpi [NetPIPE options]
To test the 1-sided communications of the MPI-2 standard, compile using:
Running as described above and MPI will use 1-sided MPI_Put() calls in both directions, with each receiver blocking until the last byte has been overwritten before bouncing the message back. Use the -f option to force usage of a fence to block rather than an overwrite of the last byte. The -g option will use MP_Get() functions to transfer the data rather than MP_Put().
Testing Pvm
Start the pvm system using:
and adding a second machine with the PVM command
add receiver_hostname
Exit the PVM command line interface using quit, then run the PVM NetPIPE receiver on one system with the command:
and run the TCP NetPIPE transmitter on the other system with the command:
NPpvm -h receiver hostname [options]
Any options used must be the same on both sides. The nplaunch script may also be used with NPpvm as described above for NPtcp.
Testing Methodology
NetPIPE tests network performance by sending a number of messages at each block size, starting from the lower bound on the message sizes.
The message size is incremented until the upper bound on the message size is reached or the time to transmit a block exceeds one second, which ever occurs first. Message sizes are chosen at regular intervals, and for slight perturbations from them to provide a more complete evaluation of the communication subsystem.
The NetPIPE output file may be graphed using a program such as gnuplot(1). The output file contains three columns: the number of bytes in the block, the transfer rate in bits per second, and the time to transfer the block (half the round-trip time). The first two columns are normally used to graph the throughput vs block size, while the third column provides the latency. For example, the throughput versus block size graph can be created by graphing bytes versus bits per second. Sample gnuplot(1) commands for such a graph would be
Options
asynchronous mode: prepost receives (MPI, IB modules) -b TCP_buffer_sizes Set the send and receive TCP buffer sizes (TCP module only). -B
Burst mode where all receives are preposted at once (MPI, IB modules).
Use a fence to block for completion (MPI2 module only).
Use MPI_Get() instead of MPI_Put() (MPI2 module only). -h hostname Specify the name of the receiver host to connect to (TCP, PVM, IB, GM). -I
Invalidate cache to measure performance without cache effects (mostly affects IB and memcpy modules).
Do an integrity check instead of a performance evaluation. -l starting_msg_size Specify the lower bound for the size of messages to be tested.
-n nrepeats Set the number of repeats for each test to a constant. Otherwise, the number of repeats is chosen to provide an accurate timing for each test. Be very careful if specifying a low number so that the time for the ping-pong test exceeds the timer accuracy. -O source_offset,dest_offset Specify the source and destination offsets of the buffers from perfect page alignment. -o output_filename Specify the output filename (default is np.out). -p perturbation_size NetPIPE chooses the message sizes at regular intervals, increasing them exponentially from the lower boundary to the upper boundary. At each point, it also tests perturbations of 3 bytes above and 3 bytes below each test point to find idiosyncrasies in the system. This perturbation value can be changed using the -p option, or turned off using -p 0 . -r
This option resets the TCP sockets after every test (TCP module only). It is necessary for some streaming tests to get good measurements since the socket window size may otherwise collapse.
Set streaming mode where data is only transmitted in one direction.
Use synchronous sends (MPI module only). -u upper_bound Specify the upper boundary to the size of message being tested. By default, NetPIPE will stop when the time to transmit a block exceeds one second. -z
Receive messages using MPI_ANY_SOURCE (MPI module only)
Set bi-directional mode where both sides send and receive at the same time (supported by most modules). You may need to use -a to choose asynchronous communications for MPI to avoid freeze-ups. For TCP, the maximum test size will be limited by the TCP buffer sizes.
Files
Default output file for NetPIPE. Overridden by the -o option.
Author
The original NetPIPE core plus TCP and MPI modules were written by Quinn Snell, Armin Mikler, Guy Helmer, and John Gustafson. NetPIPE is currently being developed and maintained by Dave Turner with contributions from many students (Bogdan Vasiliu, Adam Oline, Xuehua Chen, and Brian Smith).
Основы архитектуры IIS, или запросопровод для ASP.NET
В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.
Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.
1. Общий план
2. Крупный план
2.1. HTTP.SYS
2.2. World Wide Web Publishing Service (W3SVC)
2.3. Windows Process Activation Service (WAS)
2.4. Пул приложений
2.5. Домен приложения, приложение
3. Что дальше?
Источники
1. Общий план
Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.
Рис. 1. HTTP request processing pipeline (IIS 7.x).
Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:
1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS.
2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.
3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config).
4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS.
6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.
7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS.
8. HTTP.SYS отправляет ответ браузеру.
В принципе уже этой схемы достаточно для прохождения интервью в большинстве компаний и получения общего представления об архитектуре IIS. Но если вы не для галочки сюда зашли, то прошу следовать далее.
2. Крупный план
2.1. HTTP.SYS
На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.
Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.
Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.
Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.
Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.
2.2. World Wide Web Publishing Service (W3SVC)
- Администрирование драйвера HTTP.sys.
- Управление рабочими процессами.
- Мониторинг показателей производительности веб-сайтов.
В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).
Рис.2. Рабочий процесс со службами W3SVC и WAS.
- NetTcpActivator для протокола TCP;
- NetPipeActivator для Named Pipes;
- NetMsmqActivator для Message Queuing (ака MSMQ).
Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.
Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.
Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.
Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.
2.3. Windows Process Activation Service (WAS)
Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.
- Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
- Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
- Исполняемый файл w3wp.exe – шаблон рабочего процесса.
- Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
- Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).
Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.
Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:
А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:
В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.
Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.
2.4. Пул приложений
При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.
Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.
Рис. 5 Дополнительные настройки пула приложений
Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.
Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.
Рис. 6. Идеология модулей в IIS.
Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).
Встраиваемая модель предполагает более тесное взаимодействие между IIS и ASP.NET. Запрос в такой архитектуре обработки пропускается через установленную последовательность событий, в каждом из которых запрос пропускается через нативный и управляемые модули. В таком режиме модели обработки запросов IIS и ASP.NET объединены в единую модель, что позволяет избежать дублирования функций и получить больший контроль над обработкой запроса.
На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.
2.5. Домен приложения, приложение
Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.
Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс MyClass1 со статическим полем Field1. Итак, оба сайта работают под управлением одного пула приложений и используют одну и ту же библиотеку MyLib.dll. Веб-сайт-1 записывает в MyClass1.Field1 = 16 (рис. 7). Вопрос: увидит ли веб-сайт-2 сделанные изменения? Напрашивается ответ «Нет». Но почему? Потому что, для IIS-приложений выделяются непересекающиеся адресные пространства, даже если они работают внутри единого рабочего процесса, поэтому в память веб-приложений загружаются свои копии сборок (прошу не придираться к возможным неточностям в терминах работы с памятью в .NET Framework). 
Рис. 7. Рисунок для задачки.
Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.
3. Что дальше?
Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.
Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.