TCP协议通讯工作原理

一、TCP三次握手
  传输控制协议(Transport Control Protocol)是一种面向连接的，可靠的传输层协议。面向连接是指一次正常的TCP传输需要通过在TCP客户端和TCP服务端建立特定的虚电路连接来完成，该过程通常被称为“三次握手”。可靠性可以通过很多种方法来提供保证，在这里我们关心的是序列和确认。TCP通过数据分段(Segment)中的序列号保证所有传输的数据可以在远端按照正常的次序进行重组，而且通过确认保证数据传输的完整性。要通过TCP传输数据，必须在两端主机之间建立连接。举例说明，TCP客户端需要和TCP服务端建立连接，过程如下所示：

TCP Client	Flags	TCP
1 Send SYN (seq=w)	----SYN--->	SYN Received
2 SYN/ACK Received	<---SYN/ACK----	Send SYN (seq=x)， ACK (w+1)
3 Send ACK (x+1)	----ACK--->	ACK Received， Connection Established
w: ISN (Initial Sequence Number) of the Client
x: ISN of the Server

在第一步中，客户端向服务端提出连接请求。这时TCP SYN标志置位。客户端告诉服务端序列号区域合法，需要检查。客户端在TCP报头的序列号区中插 入自己的ISN。服务端收到该TCP分段后，在第二步以自己的ISN回应(SYN标志置位)，同时确认收到客户端的第一个TCP分段(ACK标志置位)。 在第三步中，客户端确认收到服务端的ISN(ACK标志置位)。到此为止建立完整的TCP连接，开始全双工模式的数据传输过程。

二、TCP标志

这里有必要介绍一下TCP分段中的标志(Flag)置位情况。如下图所示:

   *SYN：同步标志
　　同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

　　*ACK：确认标志
　　确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端已经成功接收所有数据。

　　*RST：复位标志
　　复位标志有效。用于复位相应的TCP连接。

　　*URG：紧急标志
　　紧急(The urgent pointer) 标志有效。紧急标志置位，

　　*PSH：推标志
　　该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。

　　*FIN：结束标志
　　带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。

三、TCP端口

 为了能够支持同时发生的并行访问请求，TCP提供一种叫做“端口”的用户接口。端口是操作系统核心用来识别不同的回话过程。这是一个严格的传输层定义。通过TCP端口和IP地址的配合使用，可以提供到达终端的通讯手段。实际上，在任一时 刻的互联网络连接可以由4个数字进行描述： 来源IP地址和来源端口，目的IP地址和目的端口。位于不同系统平台，用来提供服务的一端通过标准的端口提供相应服务。举例来说，标准的TELNET守护 进程(telnet daemon)通过监听TCP 23端口，准备接收用户端的连接请求。

四、TCP缓存(TCP Backlog)

 通常情况下，操作系统会使用一块限定的内存来处理TCP连接请求。每当用户端发送的SYN标志置位连接请求到服务端的一个合法端口(提供TCP服务的一端监听该端口)时，处理所有连接请求的内存使用量必须进行限定。如果不进行限定，系统会因处理大量的TCP连接请求而耗尽内存，这在某种程度上可以说是一种简单的DoS攻击。这块经过限定的，用于处理TCP连接的内存称为TCP缓存(TCP Backlog)，它实际上是用于处理进站(inbound)连接请求的一个队列。该队列保存那些处于半开放(half-open)状态的TCP连接项目，和已建立完整连接但仍未由应用程序通过accept()调用提取的项目。如果这个缓存队列被填满，除非可以及时处理队列中的项目，否则任何其它新的TCP连接请求会被丢弃。

  一般情况下，该缓存队列的容量很小。原因很简单，在正常的情况下TCP可以很好的处理连接请求。如果当缓存队列填满的时候新的客户端连接请求被丢弃，客户端只需要简单的重新发送连接请求，服务端有时间清空缓存队列以相应新的连接请求。

  在现实环境中，不同操作系统支持TCP缓冲队列有所不同。在BSD结构的系统中，如下所示：

OS	Backlog	BL+ Grace	Notes
SunOS 4.x.x	5	8
IRIX 5.2	5	8
1.2.x	10	10	Linux does not have this grace margin
FreeBSD 2.1.0		32
FreeBSD 2.1.5		128
WinNTs3.5.1	6	6	NT does not appear to have this margin
WinNTw4.0	6	6	NT has a pathetic backlog

五、TCP进站(Inbound)处理过程

    为了更好的讲述TCP SYN Flood的攻击过程，我们先来介绍一下正常情况下，TCP进站处理的过程。

　　服务端处于监听状态，客户端用于建立连接请求的数据包(IP packet)按照TCP/IP协议堆栈组合成为TCP处理的分段(segment)。

　　分析报头信息：TCP层接收到相应的TCP和IP报头，将这些信息到内存中。

　　检查TCP校验和(checksum)：标准的校验和位于分段之中(Figure-2)。如果检验失败，不返回确认，该分段丢弃，并等待客户端进行重传。

　　查找协议控制块(PCB{})：TCP查找与该连接相关联的协议控制块。如果没有找到，TCP将该分段丢弃并返回RST。(这就是TCP处理没有端口监听情况下的机制) 如果该协议控制块存在，但状态为关闭，服务端不调用connect()或listen()。该分段丢弃，但不返回RST。客户端会尝试重新建立连接请求。

　　建立新的socket：当处于监听状态的socket收到该分段时，会建立一个子socket，同时还有socket{}，tcpcb{}和pcb{}建立。这时如果有错误发生，会通过标志位来拆除相应的socket和释放内存，TCP连接失败。如果缓存队列处于填满状态，TCP认为有错误发生，所有的后续连接请求会被拒绝。这里可以看出SYN Flood攻击是如何起作用的。

　　丢弃：如果该分段中的标志为RST或ACK，或者没有SYN标志，则该分段丢弃。并释放相应的内存。

流量控制：
1、流量控制是管理两端的流量，以免会产生发送过块导致收端溢出，或者因收端处理太快而浪费时间的状态。用的是：滑动窗口，以字节为单位

2、窗口有3种动作：展开（右边向右），合拢（左边向右），收缩（右边向左）这三种动作受接收端的控制。
合拢：表示已经收到相应字节的确认了
展开：表示允许缓存发送更多的字节
收缩（非常不希望出现的，某些实现是禁止的）：表示本来可以发送的，现在不能发送；但是如果收缩的是那些已经发出的，就会有问题；为了避免，收端会等待到缓存中有更多缓存空间时才进行通信。
发端窗口的大小取决于收端的窗口大小rwnd（TCP报文的窗口大小字段）和拥塞窗口大小cwnd（见拥塞控制）
发端窗口大小 = min{ rwnd , cwnd };

3、关闭窗口：窗口缩回有个例外，就是发送rwnd=0表示暂时不愿意接收数据。这种情况下，发端不是把窗口收缩，二是停止发送数据。（为了比避免死锁，会用一些探测报定时发送试探，见定时器一节）

4、问题：某些时候，由于发端或收端的数据很慢，会引起大量的1字节数据痛惜，浪费很多资源。
（1）、发端的进程产生数据很慢时候，时不时的来个1字节数据，那么TCP就会1字节1字节的发送，效率很低。
解决方法（Nagle算法）：
a、将第一块数据发出去
b、然后等到发送缓存有足够多的数据（最大报文段长度），或者等到收端确认的ACK时再发送数据。
c、重复b的过程
（2）、收端进程由于消耗数据很慢，所以可能会有这么一种情况，收端会发送其窗口大小为1的信息，然后有是1字节的传输
解决办法（2种）
a、Clark方法：在接收缓存的一半变空，或者有足够空间放最大报文长度之前，宣告接收窗口大小为0
b、推迟确认：在对收到的报文段确认之前等待到足够的接收缓存，或者等待到一个时间段（现在一般定义500ms）

拥塞控制：
1、如果网络上的负载（发送到网络上的分组数）大于网络上的容量（网络同时能处理的分组数），就可能引起拥塞，判断网络拥塞的两个因素：延时和吞吐量。拥塞控制机制是：开环（预防）和闭环（消除）（见网络原理相关书籍，略）
tcp处理拥塞的三种策略：慢启动（指数增大），拥塞避免（加法增大），拥塞检测（除2减少，或叫做乘法减少）

2、慢启动：指数增大
/* ssthresh是慢开始门限，slow start threshold表示一个上限，一般的实现为65535B */
cwnd = 1;(1表示一个MSS报文段，不是一个字节)
while （ cwnd < ssthresh )
    if（ 发出的报文段确认 ）
       cwd *= 2;

3、拥塞避免：加法增大
当到达ssthresh之后，就是加法阶段了，每收到一个确认，cwd += 1；      
 
4、拥塞检测：乘法减少（除2减少）
当报文需要重传时，说明拥塞可能发生了，由于重传有2种情况，所以也分两种处理
（1）、由于超时重传，这是拥塞的可能性比较大，如下做强反映调整
a、 ssthresh /= 2;
b、 cwnd = 1；
重新慢启动过程
（2）、由于收到3个重复的ACK的重传，采取弱反映：
a、ssthresh /= 2;
b、cwnd = ssthresh;
c、开始拥塞避免过程

差错控制：
1、TCP必须保证数据：按序，没有差错，没有部分丢失，没有重复的交给应用层。方法就是：校验和，确认，超时重传

2、校验和：和UDP的做法一样，也要伪首部，和UDP不同的是这个功能在TCP中是必须的

3、确认：ACK的确认机制（下面是一些原则）
a、ACK报文不需要确认，也不消耗序号
b、当一端发送数据时，尽量包含捎带确认。
c、收端推迟发送ACK报文段，如果仅有一个未确认的按序报文段；延迟到500ms，或者有第二个报文段接收时（转d），或者有数据要发送时（转b）
d、任何时候,不能有两个（以上）未确认的报文段（就是说如果收端有两个未确认的按序报文段，就马上发送ACK报文段进行确认）
e、当收到一个序号比期望序号还大的报文段时，马上发送ACK，让发端进行快重传
f、收到重复的报文段，就立即发送确认(解决ACK丢失问题)
g、丢失的报文段到达，发送确认，表示已经收到了丢失的报文

4、确认类型
累计确认：收端忽略掉所有失序报文，告知发端他期待下一个收到的序号，叫做肯定累计ACK。肯定是说：丢弃的，丢失的，重复的都不报告。
选择确认（SACK）：在某些新TCP实现里面实现了这个东西，报告失序和重复的数据，作伪TCP首部选项字段的一部分。

5、重传（两种情况） ： 重传定时器时间到，或者 发端收到重复的三个ACK（快重传）