TCP协议是TCP/IP协议族中一个重要的协议。和IP协议相比,TCP协议更靠近应用层,因此在应用程序中具有更强的可操作性。一些重要的socket选项都和TCP协议相关。 TCP头部信息:TCP头部信息出现在每个TCP报文段中,用于指定通信的源端端口号,目的端端口号,管理TCP连接,控制两个方向的数据流。 TCP状态转移过程:TCP连接的任意一端都是一个状态机。在TCP连接从建立到断开的整个过程中,连接两端的状态机将经历不同的状态变迁。 TCP数据流:通过分析TCP数据流,我们就可以从网络应用程序外部来了解应用层协议和通信双方交换的应用程序数据。 TCP数据流的控制:为了保证可靠传输和提高网络通信质量,内核需要对TCP数据流进行控制(超时重传 和 拥塞控制)。 TCP服务的特点传输层协议主要有:TCP协议 和 UDP协议。 使用TCP协议通信的双方必须先建立连接,然后才能开始数据的读写。 TCP协议的这种连接是一对一的,所以基于广播和多播(目标是多个主机地址)的应用程序不能使用TCP服务,而无连接协议UDP则非常适合于广播和多播。 字节流服务和数据报服务的区别,这种区别对应到实际编程中,则体现为通信双方是否必须执行相同次数的读,写操作(这只是表现形式)。 当接收端收到一个或多个TCP报文段后,TCP模块将它们携带的应用程序数据按照TCP报文段的序号以此放入TCP接收缓冲区中,并通知应用程序读取数据。 综上所述,发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系,这是字节流的概念(应用程序对数据的发送和接收是没有边界限制的)。 UDP:发送端应用程序每执行一次写操作,UDP模块就将其封装成一个UDP数据报并发送。接收端必须及时针对每一个UDP数据报执行读操作,否则就会丢包(发生在较慢的服务器上)。 并且如果用户没有指定足够的应用程序缓冲区来读取UDP数据,则UDP数据将被截断。 两者区别如图: TCP传输时可靠的。 TCP协议采用发送应答机制,即发送端发送的每个TCP报文段都必须得到接收方的应答,才认为这个TCP报文段传输成功。 TCP协议采用超时重传机制,发送端在发送出一个TCP报文段之后启动定时器,如果在定时时间内未收到应答,它将重发该报文段。 因为TCP报文段最终是以IP数据报发送的,而IP数据报到达接收端可能乱序,重复,所以TCP协议还会对接收到的TCP报文段重排,整理,再交付给应用层。 UDP协议则和IP协议一样,提供不可靠服务。它们都需要上层协议来处理数据确认和超时重传。 TCP头部结构TCP固定头部结构16位端口号:告知主机该报文段是来自哪里(源端口)以及传给哪个上层协议或应用程序(目的端口)的。客户端一般使用系统自动选择的临时端口号,服务端一般使用知名服务端口号(/etc/services 文件中可查看) 32位序号:一次TCP通信(从TCP连接建立到断开)过程中某一个传输方向上的字节流的每个字节编号,在通信的第一个TCP报文段中,序号值为某个随机值ISN,确认号为0。(例如:某个TCP报文段传送的数据是字节流中的第1025~2048字节,那么该报文段的序号值就是ISN+1025。另一个传输方向同理)。 32位确认号:用作对另一方发送来的TCP报文段的响应。其值是收到的TCP报文段的序号值加1。 4位头部长度:标识该TCP头部有多少个4 字节 。 TCP头部最长是60字节。 6位标志位包含如下几项: 16位窗口大小:是TCP流量控制的一个手段。这里的窗口指的是接受通告窗口(Receiver Window,RWND)。它告诉对方本端的TCP接受缓冲区还能容纳多少字节的数据,对方以此控制发送数据的速度。 16位校验和:由发送端填充,接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意,这个校验不仅包括TCP头部,也包括数据部分,这也是TCP可靠传输的一个重要保障。 16位紧急指针:是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此,确切地说,这个字段是紧急指针相对当前序号的偏移,不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。 TCP头部选项TCP头部的最后一个选项字段是可变长的可选信息,这部分最多包含40字节,因为TCP头部最长是60字节(包含20字节的固定部分)。 选项的第一个字段kind说明选项的类型(有的TCP选项没有后两个字段,仅包含1字节的kind字段)。第二个字段length字段占据的2字节。第三个字段info(如果有的话)是选项的具体信息。 kind=0是选项表结束选项。 kind=1是空操作(nop)选项,没有特殊含义,一般用于将TCP选项的总长度填充为4字节的整数倍。 kind=2是最大报文段长度选项。 kind=3是窗口扩大因子选项。 kind=4是选择性确认(SACK)选项。 kind=5是SACK实际工作的选项。 kind=8是时间戳选项。 TCP连接的建立和关闭前三个报文段是三次握手的步骤,用来建立连接。 后四个报文段是四次挥手的步骤,用来关闭连接。 半关闭状态TCP连接是全双工的,所以它允许两个方向的数据传输被独立关闭。还言之,通信的一端可以发送结束报文段给对方,告诉它本端已经完成数据的发送,但允许继续接收来自对方的数据,直到对方也发送结束报文段以关闭连接。这种状态被称为半关闭。 而判断对方是否已经关闭连接的方法是:read函数调用返回0。
连接超时前面我们讨论的是很快建立连接的情况。如果客户端访问一个距离它很远的服务器,或者由于网络繁忙,导致服务器对客户端发送处的同步报文段没有应答,此时客户端程序如果是提供可靠服务的TCP,它必然是先进行重连(可能执行多次),如果重连仍无效,则通知应用程序连接超时。 TCP状态转移图中的粗虚线表示典型的服务器端连接的状态转移;粗实线表示典型的客户端连接的状态转移。CLOSED是一个假想的起始点,不是一个实际的状态。 服务器通过listen系统调用进入LISTEN状态,被动等待客户端连接,因此执行的是所谓的被动打开。服务器一旦监听到某个连接请求(收到同步报文段),就将该连接放入内核等待队列中,并向客户端发送带SYN标志的确认报文段。此时该连接处于SYN_RCVD状态。 当客户端主动关闭连接时,服务器通过返回确认报文段使连接进入CLOSED_WAIT状态。这个状态的含义是:等待服务器应用程序关闭连接。通常,服务器检测到客户端关闭连接后,也会立即给客户端发送一个结束报文段来关闭连接。 客户端通过connect系统调用主动与服务器建立连接。Connect系统调用首先给服务器发送一个同步报文段,使连接转移到SYN_SENT状态。此后,connect系统调用可能因为如下两个原因失败返回: 连接停留在FIN_WAIT_2状态的情况可能发生在:客户端执行半关闭后,未等服务器关闭连接就强行退出了。 TIME_WAIT状态客户端连接在收到服务器的结束报文段之后,并没有直接进入CLOSED状态,而是转移到TIME_WAIT状态。这个状态,客户端连接要等待一段长为2MSL(报文段最大生存时间)的时间,才能完全关闭。MSL是TCP报文段在网络中的最大生存时间,建议值是2min 。 TIME_WAIT状态存在的原因有两点: 为什么要坚持2MSL的原因: TCP超时重传TCP服务必须能够重传超时时间内未收到的TCP报文段。为此,TCP模块为每个TCP报文段都维护一个重传定时器,该定时器在TCP报文段第一次被发送时启动。如果超时时间内为接收到接收方的应答,TCP模块将重传TCP报文段并重置定时器。至于下次重传的超时时间如何选择,以及最多执行多少次重传,就是TCP的重传策略。 Linux有两个重要的内核参数与TCP超时重传相关:/proc/sys/net/ipv4/tcp_retries1和/proc/sys/net/ipv4/tcp_retries2。前者指定在底层IP接管之前TCP最少执行的重传次数,默认值是3。后者指定连接放弃前TCP最多可以执行可以执行的重传次数,默认值是15(一般对应13~30min)。 拥塞控制拥塞控制概述TCP模块还有一个公平的任务,就是提高网络利用率,降低丢包率,并保证网络资源对每条数据流的公平性。这就是作为的拥塞控制。 TCP拥塞控制的四个部分分别是:慢启动,拥塞避免,快速重传和快速恢复。 拥塞控制的最终受控变量是发送端向网络一次连续写入(收到其中第一个数据确认之前)的数据量,我们称为SWND(发送窗口)。不过,发送端最终以TCP报文段来发送数据,所以SWND限定了发送端能连续发送的TCP报文段数量。这些TCP报文段的最大长度(仅指数据部分)称为SMSS(发送者最大段大小),其值一般等于MSS。 发送端需要合理的选择SWND的大小。如果SWND太小,会引起明显的网络延迟;如果SWND太大,则容易导致网络拥塞。前文提到,接收方可通过其接收通告窗户(RWND)来控制发送端的SWND。但这显然不够,所以发送端引入了一个称为拥塞窗户(CWND)的状态变量。实际的SWND值是RWND和CWND中的较小者。 慢启动和拥塞避免慢启动:TCP连接好之后,CWND将被设置成初始值IW(Initial window),其大小为2~4个SMSS。此时发送端最多能发送IW字节的数据。此后发送端每收到接收端的一个确认,其CWND就按照值数形式扩大,这就是所谓的慢启动。 慢启动算法的理由:TCP模块刚开始发送数据时并不知道网络的实际情况,需要以一种试探的方式平滑的增加CWND的大小。 拥塞避免:但是如果不施加其他手段,慢启动必然使得CWDN很快膨胀(可见慢启动实际不慢)并最终导致网络拥塞。因此TCP拥塞控制中定义了另一个重要的状态变量:慢启动门限(ssthresh)。当CWDN的大小超过该值时,TCP拥塞控制进入拥塞避免阶段。 拥塞避免算法使得CWDN按照线性方式增加,从而减缓其扩大。 举例如下图: 发送端判断拥塞发生的依据有如下两个:
|
|