一个简单的服务器程序步骤：

说明：1.创建TCP套接口

     2.捆绑服务器的众所周知端口

     3.把套接口变换成监听套接口

     4.接受客户连接，发送应答，服务器进程在调用accept函数后处于睡眠状态，它等待客户的连接和内核对它的接受。TCP连接使用三路握手来建立，当握手完毕，accept函数返回，其返回值是一个已连接描述字的新描述字。

OSI模型

第二章  传输层：TCP和UDP

UDP：用户数据报协议

我们称UDP提供无连接服务，因为UDP客户与服务器不必存在长期的关系。例如：一个UDP客户可以创建一个套接口并发送一个数据报给一个服务器，然后立即用同一个套接口发送另一个数据报给另一个服务器。同样，一个UDP服务器可以用用以个UDP套接口从5个不同的客户一连串接受5个数据报。

TCP:传输控制协议

首先，TCP提供客户与服务器的连接；

其次，TCP提供可靠性；

第三，TCP通过给所发送数据的每一个字节关联一个序列号进行排序；

第四，TCP提供流量控制；TCP总是告诉对方它能够接受多少字节的数据，这称为通告窗口。

最后，TCP连接时全双工的；

TCP连接的建立和终止

建立一个TCP连接时，会发生下述情形：

1、服务器端必须做好准备接受外来的连接。这通常通过 socket(), bind(), listen() 三个函数来完成的。我们称之为 被动打开(passive open).

2、客户端通过调用connect发起主动打开(active open)。这导致客户端TCP发送SYN同步分节。它告诉服务器客户端在(待建立的)连接中发送的数据的初始化序列号。通用SYN分节不携带数据，

3、服务器必须确认(ACK) 客户端的SYN，同时自己也得发送一个SYN分节，它含有服务器将在统一连接中发送的数据的初始化序号。服务器在单个分节中发送SYN和对客户端SYN的ACK确认。

4、客户端必须确认服务器的SYN。

     建立TCP连接的日常系统类比是电话系统[Nemeth 1997].socket函数等同于有电话可用.bind用于告诉其他人你的电话号码,让他们可以向你打电话.listen是打开电话振铃,它使你可以听到一个外来的电话.connect要求你知道另一方的电话号码并拨打它.accept是被呼叫回电话.从accept返回客户的标识(即客户的IP地址和端口号)类似于让电话机的呼叫者ID功能部件显示打电话人的电话号码.然而有点不同的地方是:从accept返回客户的标识是在建立连接以后,而呼叫者ID功能部件显示打电话人的电话号码是在我们选择接或不接电话之前.如果使用域名系统(第9章),那么提供了一种类似于电话薄的服务.gethostbyname类似于在电话薄查找个人的电话号码.gethostbyaddr则类似于有一种电话薄按电话号码排序

SYN洪水攻击

     假设一个C向S发送了SYN后无故消失了,那么S在发出SYN+ACK应答报文后是无法收到C的ACK报文的(第三次握手无法完成),这种情况下S一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个C出现异常导致S的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,S将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试.实际上如果S的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使S的系统足够强大,S也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟C的正常请求比率非常之小),此时从正常客户的角度看来,S失去响应,这种情况我们称作:服务器端受到了SYN Flood攻击(SYN洪水攻击).

TCP连接的终止：

1、某个应用程序首先调用close，主动关闭(active close) 该端的TCP于是发送一个FIN分节，表示数据发送完毕。

2、接收到这个FIN的对端执行被动关闭(passive close)。这个FIN是TCP确认。它的接收也作为一个文件结束符(end of file) 传递给接收端的应用程序(放在排队等候应用进程接收的任何其他数据之后)，因为FIN的接收意味着接收端应用程序在相应连接上再无额外数据可以接收。

3、一段时间以后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。

4、接收这个最终FINd额原发送端TCP(即执行主动关闭的一端)确认这个FIN

注意：执行主动关闭的那一端（客户端）进入TIME_WAIT状态。

TIME_WAIT状态：

TCP中有关网络编程最不容易理解的是它的TIME_WAIT状态。执行主动关闭的那端进入这种状态，该端点停留在这种状态的持续时间是最长分节生命周期(MSL)的两倍，有时候称之为2MSL。

存在TIME_WATI状态有两个理由：

1、可靠地实现TCP全双工连接的终止。

2、允许老的重复分节在网络中消逝。

     第一个理由的解释如下：假设TCP连接终止的最终的ACK丢失，服务器将重发最终的FIN，因此客户必需维护状态信息，以允许它重发最终的ACK。要是不维护状态信息，它将响应以RST，而服务器则把该分节解释成一个错误。

要理解存在TIME_WAIT状态的第二个理由，我们假设在12.106.32.254的端口1500和206.168.112.219的端口21之间有一个TCP连接。我们关闭这个连接后，在以后某个时候又重新建立起相同的IP和端口之间的TCP连接。后一个连接称为前一个连接的化身，因为它的IP地址和端口号都相同。TCP必须防止来自某个连接的老的重复分组在该链接已经终止后再现，从而被误解成属于同一连接的新化身。为做到这一点，TCP将不给处于TIME_WAIT状态的连接启动新的化身。既然TIME_WAIT状态持续的时间是2MSL，这就足够允许某个方向上的分组最多存活MSL秒即被丢弃，另一个方向上的应答最多存活MSL秒也被丢弃。通过实施这个规则，我们能够保证每当成果建立一个TCP连接时，来自该连接先前化身的老的重复分组都已在网络中消逝。

端口分配：

Unix系统有保留端口的概念，它是小于1024的任何端口。这些端口只能分配给超级用户进程的套接口。所有众所周知的端口都为保留端口，因此分配这些端口的服务器启动时必须具有超级用户的特权。

套接口对：

标识每个端点的两个值（IP地址和端口号）通常称为一个套接口。

套接口发送缓冲区：

上面是TCP的缓冲区，从一个TCP套接口的write调用成功返回仅仅表示我们可以重新使用应用进程的缓冲区，它并不告诉我们对方的TCP或对方应用进程已接受到数据。而UDP是不可靠的，它不必保存应用进程的数据拷贝，因此无需一个真正的发送缓冲区。