来自：网络整理
个人觉得写一个网络应用程序没有是一件非常easy的事。其实，我们刚開始的时候总觉得的原则：
建立------》连接套接字-------》接受一个连接----》发送数据
而真正复杂编写一个网络应用程序的规模从一个连接到成千上万的连接！
那么本系列将对sockt由浅入深的介绍.
msdn
The overlapped I/O mechanism in Win32® allows an application to initiate an operation and receive notification of its completion later. This is especially useful for operations that take a long time to complete. The thread that initiates the overlapped operation is then free to do other things while the overlapped request completes behind the scenes. The only I/O model that provides true scalability on Windows NT and Windows 2000 is overlapped I/O using completion ports for notification. Mechanisms like the WSAAsyncSelect and select functions are provided for easier porting from Windows 3.1 and Unix respectively, but are not designed to scale. The completion port mechanism is optimized for the operating system's internal workings.
A completion port is a queue into which the operating system puts notifications of completed overlapped I/O requests. Once the operation completes, a notification is sent to a worker thread that can process the result. Asocket may
be associated with a completion port at any point after creation.
Typically an application will also create a number of worker threads to process these notifications. The number of worker threads depends on the specific needs of the application. The ideal number is one per processor, but that implies that none of these
threads should execute a blocking operation such as a synchronous read/write or a wait on an event. Each thread is given a certain amount of CPU time, known as the quantum, for which it can execute before another thread is allowed to grab a time slice. If
a thread performs a blocking operation, the operating system will throw away its unused time slice and let other threads execute instead. Thus, the first thread has not fully utilized its quantum, and the application should therefore have other threads ready
to run and utilize that time slot.
Using a completion port is a two-step process. First, the completion port is created, as shown in the following code:
上面来自msdn的一个解释，简单的介绍了“完毕port”模型 ： I/O 与socket 的关系映射 重叠线程，“完毕port”模型这个是一个比較复杂的I/O模型，首先要创建一个I/O完毕port对象。用它面向随意数量的套接字句柄，管理多个I/O请求。要做到这一点。须要调用CreateCompletionPort函数
HANDLE hIocp;
hIocp = CreateIoCompletionPort(
INVALID_HANDLE_VALUE,
NULL,
(ULONG_PTR)0,
0);
if (hIocp == NULL) {
// Error
}要写网络程序就必须用Socket，这是程序猿都知道的。
并且，面试的时候，我们也会问对方会不会Socket编程？一般来说，非常多人都会说。Socket编程基本就是listen，accept以及send，write等几个主要的操作。是的，就跟常见的文件操作一样，仅仅要写过就一定知道。
对于网络编程，我们也言必称TCP/IP，似乎其他网络协议已经不存在了。
对于TCP/IP。我们还知道TCP和UDP，前者能够保证数据的正确和可靠性，后者则同意数据丢失。最后，我们还知道，在建立连接前，必须知道对方的IP地址和port号。
除此，普通的程序猿就不会知道太多了。非常多时候这些知识已经够用了。最多，写服务程序的时候，会使用多线程来处理并发訪问。
我们还知道例如以下几个事实：
1。一个指定的port号不能被多个程序共用。比方，假设IIS占用了80port。那么Apache就不能也用80port了。
2。非常多防火墙仅仅同意特定目标port的数据包通过。
3。服务程序在listen某个port并accept某个连接请求后，会生成一个新的socket来对该请求进行处理。
于是，一个困惑了我非常久的问题就产生了。
假设一个socket创建后并与80port绑定后，是否就意味着该socket占用了80port呢？假设是这种，那么当其accept一个请求后。生成的新的socket究竟使用的是什么port呢（我一直以为系统会默认给其分配一个空暇的port号）？假设是一个空暇的port，那一定不是80port了，于是以后的TCP数据包的目标port就不是80了--防火墙一定会组织其通过的。实际上，我们能够看到，防火墙并没有阻止这种连接。并且这是最常见的连接请求和处理方式。
我的不解就是，为什么防火墙没有阻止这种连接？它是怎样判定那条连接是由于connet80port而生成的？是不是TCP数据包里有什么特别的标志？或者防火墙记住了什么东西？
后来，我又细致研读了TCP/IP的协议栈的原理。对非常多概念有了更深刻的认识。比方，在TCP和UDP同属于传输层，共同架设在IP层（网络层）之上。而IP层主要负责的是在节点之间（End to End）的数据包传送，这里的节点是一台网络设备。比方计算机。由于IP层仅仅负责把数据送到节点。而不能区分上面的不同应用。所以TCP和UDP协议在其基础上增加了port的信息。port于是标识的是一个节点上的一个应用。除了增加port信息，UPD协议基本就没有对IP层的数据进行不论什么的处理了。而TCP协议还增加了更加复杂的传输控制。比方滑动的数据发送窗体（Slice Window），以及接收确认和重发机制，以达到数据的可靠传送。无论应用层看到的是如何一个稳定的TCP数据流，以下传送的都是一个个的IP数据包。须要由TCP协议来进行数据重组。
所以。我有理由怀疑。防火墙并没有足够的信息推断TCP数据包的很多其它信息，除了IP地址和port号。并且。我们也看到。所谓的port。是为了区分不同的应用的，以在不同的IP包来到的时候可以正确转发。
TCP/IP仅仅是一个协议栈，就像操作系统的执行机制一样，必需要详细实现，同一时候还要提供对外的操作接口。
就像操作系统会提供标准的编程接口。比方Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket编程接口--原来是这么回事啊！
在Socket编程接口里，设计者提出了一个非常重要的概念，那就是socket。这个socket跟文件句柄非常相似，实际上在BSD系统里就是跟文件句柄一样存放在一样的进程句柄表里。
这个socket事实上是一个序号，表示其在句柄表中的位置。这一点，我们已经见过非常多了。比方文件句柄，窗体句柄等等。
这些句柄，事实上是代表了系统中的某些特定的对象，用于在各种函数中作为參数传入。以对特定的对象进行操作--这事实上是C语言的问题，在C++语言里，这个句柄事实上就是this指针，实际就是对象指针啦。
如今我们知道，socket跟TCP/IP并没有必定的联系。Socket编程接口在设计的时候，就希望也能适应其它的网络协议。
所以。socket的出现仅仅是能够更方便的使用TCP/IP协议栈而已。其对TCP/IP进行了抽象，形成了几个最主要的函数接口。
比方create，listen，accept，connect，read和write等等。
如今我们明确。假设一个程序创建了一个socket，并让其监听80port，事实上是向TCP/IP协议栈声明了其对80port的占有。以后，全部目标是80port的TCP数据包都会转发给该程序（这里的程序，由于使用的是Socket编程接口，所以首先由Socket层来处理）。
所谓accept函数，事实上抽象的是TCP的连接建立过程。accept函数返回的新socket事实上指代的是本次创建的连接。而一个连接是包括两部分信息的。一个是源IP和源port，还有一个是宿IP和宿port。所以。accept能够产生多个不同的socket。而这些socket里包括的宿IP和宿port是不变的。变化的仅仅是源IP和源port。
这种话，这些socket宿port就能够都是80，而Socket层还是能依据源/宿对来准确地分辨出IP包和socket的归属关系。从而完毕对TCP/IP协议的操作封装！
而同一时候，放火墙的对IP包的处理规则也是清晰明了。不存在前面设想的种种复杂的情形。
明确socket仅仅是对TCP/IP协议栈操作的抽象，而不是简单的映射关系，这非常重要