TCP协议
简介 TCP协议，即传输控制协议，与UDP协议同处于传输层，使用相同的网络层，但TCP提供了一种可靠的、面向连接的数据传输服务，它会在两个使用TCP的应用之间建立一个TCP连接，在该连接上进行数据的传输。
TCP通过以下方式提供可靠性：
1、应用程序被分割成TCP认为最合适发送的数据块。这点与UDP完全不同，应用程序产生的UDP数据报长度将保持不变，加上IP首部后，才会进行IP分片。
2、当TCP发出一个报文段后，它会启动一个定时器，等待目的端发确认收到这个报文段，如果没能及时收到该确认信息，则将重发这个报文段。
3、当TCP接收端收到发送端发来的TCP报文段时，它将发送一个确认，这个确认不是立即发送的，通常会推迟几分之一秒。
4、TCP将保持它首部和数据的校验和。这是一个端到端的校验和，如果收到的报文段的校验和有差错，TCP将丢弃该报文段，同时不发送确认收到的消息，从而使发送端超时重发。
5、TCP能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间，TCP的接受端只允许另一端发送接收端缓冲区所能接纳的数据，这将防止较快主机致使较慢主机的缓冲区溢出。
6、由于TCP报文段作为IP数据报来传输，IP数据报的到达可能会失序，因此TCP报文段的到达也可能失序，如果必要，TCP将对收到的数据进行重排序，将收到的数据以正确的顺序交给应用层。
7、由于IP数据报有可能发生重复，TCP的接收端必须丢弃重复的数据。
TCP连接的建立和释放 TCP报文
文章图片
首部固定部分的各字段的意义如下：
1、源端口和目的端口：加上IP首部的源IP地址和目的IP地址，确定唯一的一个TCP连接。另外通过目的端口来决定TCP将数据报交付于那个应用程序，从而实现TCP的分用功能。
2、序号：占4个字节，序号的范围为[0,4284967296]。由于TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，首部中的序号字段则是指本报文段所发送的数据的第一个字节的序号。另外，序号是循环使用的，当序号增加到最大值时，下一个序号就又回到了0。
3、**确认号：**当ACK标志位为1时有效，表示期望收到的下一个报文段的第一个数据字节的序号。确认号为N，则表明到序号N-1为止的所有数据字节都已经被正确地接收到了。
4、头部长度：TCP报文段的头部长度，它指出TCP报文段的数据部分的起始位置与TCP报文段的起始位置的距离。头部长度占4个字节，但它的单位是32位字，即以4字节为计算单位，因此头部长度的最大值为15*4=60个字节，这就意味着选项的长度不超过40个字节。
5、**保留位：**必须为0.
6、下面的六个控制位说明报文段的性质：
1）URG：与首部中的紧急指针字段配合使用。URG为1时，表明紧急指针字段有效，发送应用进程告诉发送方的TCP有紧急数据要传送，于是发送方TCP就把紧急数据插入到本报文段数据的最前面，而其后面仍是普通数据。
2）ACK：仅当ACK=1时确认号字段才有效，当ACK=0时，确认号无效。TCP规定，在连接建立后所有的传送报文段都必须把ACK置1。
3）PSH：如果发送的报文段中PSH为1，则接收方接受到该报文段后，直接将其交付给应用进程，而不再等待整个缓存都填满后再向上交付。
4）RST：复位标志，RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后重新建立运输连接。
5）SYN：同步序号，用来发起一个连接。当SYN=1而ACK=0时，表明这是一个连接请求报文段，若对方同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。
6）FIN：用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放连接。
7、窗口：接收方让发送方下次发送报文段时设置的发送窗口的大小。
8、校验和：校验的字段范围包括首部和数据这两部分。
9、紧急指针：紧急指针当URG=1时才有效，它指出本报文段中的紧急数据的字节数。值得注意的是，即使窗口为0时，也可发送紧急数据。
10、选项与填充：选项应该为4字节的整数倍，否则用0填充。最常见的可选字段是最长报文大小MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。该选项如果不设置，默认为536（20+20+536=576字节的IP数据报），其中ip首部和tcp首部各20个字节，而internet 上标准的MTU （最小）为576B。
下图为TCP三次握手连接的建立过程：
文章图片
服务端的TCP进程先创建传输控制块TCB，准备接受客户端进程的连接请求，然后服务端进程处于LISTEN状态，等待客户端的连接请求，如有，则作出响应。
1、客户端的TCP进程也首先创建传输控制模块TCB，然后向服务端发出连接请求报文段，该报文段首部中的SYN=1，ACK=0，同时选择一个初始序号seq=i。TCP规定，SYN=1的报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入**SYN—SENT（**同步已发送）状态，这是TCP连接的第一次握手。
2、服务端收到客户端发来的请求报文后，如果同意建立连接，则向客户端发送确认。确认报文中的SYN=1，ACK=1，确认号ack=i+1，同时为自己选择一个初始序号seq=j。同样该报文段也是SYN=1的报文段，不能携带数据，但同样要消耗掉一个序号。这时，TCP服务端进入**SYN—RCVD（同步收到）**状态，这是TCP连接的第二次握手。
3、TCP客户端进程收到服务端进程的确认后，还要向服务端给出确认。确认报文段的ACK=1，确认号ack=j+1，而自己的序号为seq=i+1。TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号，因此，如果不携带数据，则下一个报文段的序号仍为seq=i+1。这时，TCP连接已经建立，客户端进入ESTABLISHED（已建立连接）状态。这是TCP连接的第三次握手，可以看出第三次握手客户端已经可以发送携带数据的报文段了。
当服务端收到确认后，也进入**ESTABLISHED（已建立连接）**状态。
双方同时主动连接的TCP连接建立过程
正常情况下，传输连接都是由一方主动发起的，但也有可能双方同时主动发起连接，此时就会发生连接碰撞，最终只有一个连接能够建立起来。因为所有连接都是由它们的端点进行标识的。如果第一个连接请求建立起一个由套接字（x,y）标识的连接，而第二个连接也建立了这样一个连接，那么在TCP实体内部只有一个套接字表项。
当出现同时发出连接请求时，则两端几乎在同时发送一个SYN字段置1的数据段，并进入SYN_SENT状态。当每一端收到SYN数据段时，状态变为SYN_RCVD，同时它们都再发送SYN字段置1，ACK字段置1的数据段，对收到的SYN数据段进行确认。当双方都收到对方的SYN+ACK数据段后，便都进入ESTABLISHED状态。图10-39显示了这种同时发起连接的连接过程，但最终建立的是一个TCP连接，而不是两个，这点要特别注意。
文章图片
从图中可以看出，一个双方同时打开的传输连接需要交换数据段，比正常的传输连接建立所进行的三次握手多交换一个数据段。此外要注意的是，此时我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。
为什么一定要进行三次握手呢？
前两次的握手很显然是必须的，主要是最后一次，即客户端收到服务端发来的确认后为什么还要想服务端再发送一次确认呢？这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。
考虑如下的情况：客户端发送了一个连接请求报文段到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段该服务端，而后正常建立连接，数据传输完毕，并释放了连接。如果这时候第一次发送的请求报文段延迟了一段时间后，又到了服务端，很显然，这本是一个早已失效的报文段，但是服务端收到后会误以为客户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。假设不采用三次握手，这时服务端只要发送了确认，新的连接就建立了，但由于客户端比你更没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却认为新的连接已经建立了，并在一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务器的资源。而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。
下图为TCP四次挥手的释放过程：
文章图片
数据传输结束后，通信的双方都可以释放连接，并停止发送数据。假设现在客户端和服务端都处于ESTABLISHED状态。
1、客户端A的TCP进程先向服务端发出连接释放报文段，并停止发送数据，主动关闭TCP连接。释放连接报文段中FIN=1，序号为seq=u，该序号等于前面已经传送过去的数据的最后一个字节的序号加1。这时，A进入FIN—WAIT-1（终止等待1）状态，等待B的确认。TCP规定，FIN报文段即使不携带数据，也要消耗掉一个序号。这是TCP连接释放的第一次挥手。
2、B收到连接释放报文段后即发出确认释放连接的报文段，该报文段中，ACK=1，确认号为ack=u+1，其自己的序号为v，该序号等于B前面已经传送过的数据的最后一个字节的序号加1。然后B进入**CLOSE—WAIT（关闭等待）**状态，此时TCP服务器进程应该通知上层的应用进程，因而A到B这个方向的连接就释放了，这时TCP处于半关闭状态，即A已经没有数据要发了，但B若发送数据，A仍要接受，也就是说从B到A这个方向的连接并没有关闭，这个状态可能会持续一些时间。这是TCP连接释放的第二次挥手。
3、A收到B的确认后，就进入了FIN—WAIT（终止等待2）状态，等待B发出连接释放报文段，如果B已经没有要向A发送的数据了，其应用进程就通知TCP释放连接。这时B发出的链接释放报文段中，FIN=1，确认号还必须重复上次已发送过的确认号，即ack=u+1，序号seq=w，因为在半关闭状态B可能又发送了一些数据，因此该序号为半关闭状态发送的数据的最后一个字节的序号加1。这时B进入LAST—ACK（最后确认）状态，等待A的确认，这是TCP连接的第三次挥手。
4、A收到B的连接释放请求后，必须对此发出确认。确认报文段中，ACK=1，确认号ack=w+1，而自己的序号seq=u+1，而后进入TIME—WAIT（时间等待）状态。这时候，TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态，时间MSL叫做最长报文寿命，RFC建议设为2分钟，因此从A进入TIME—WAIT状态后，要经过4分钟才能进入到CLOSED状态，而B只要收到了A的确认后，就进入了CLOSED状态。二者都进入CLOSED状态后，连接就完全释放了，这是TCP连接的第四次挥手。
*双方主动关闭的TCP连接释放流程*
与可以双方同时建立TCP传输连接一样，TCP传输连接关闭也可以由双方同时主动进行（正常情况下都是由一方发送第一个FIN数据段进行主动连接关闭，另一方被动接受连接关闭）
文章图片
当两端对应的网络应用层进程同时调用CLOSE原语，发送FIN数据段执行关闭命令时，两端均从ESTABLISHED状态转变为FIN WAIT 1状态。任意一方收到对端发来的FIN数据段后，其状态均由FIN WAIT 1转变到CLOSING状态，并发送最后的ACK数据段。当收到最后的ACK数据段后，状态转变化TIME_WAIT，在等待2MSL后进入到CLOSED状态，最终释放整个TCP传输连接。
为什么A在TIME—WAIT状态必须等待2MSL时间呢？
1、为了保证A发送的最后一个ACK报文段能够到达B。该ACK报文段很有可能丢失，因而使处于在LIST—ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B可能会重传这个FIN+ACK报文段，而A就在这2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入CLOSED状态。如果A在TIME—WAIT状态不等待一段时间就直接释放连接，到CLOSED状态，那么久无法收到B重传的FIN+ACK报文段，也就不会再发送一次确认ACK报文段，B就无法正常进入CLOSED状态。
2、防止已失效的请求连接出现在本连接中。在连接处于2MSL等待时，任何迟到的报文段将被丢弃，因为处于2MSL等待的、由该插口（插口是IP和端口对的意思，socket）定义的连接在这段时间内将不能被再用，这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。
补充：
当客户端执行主动关闭并进入TIME—WAIT是正常的，服务端执行被动关闭，不会进入TIME—WAIT状态，这说明，如果终止了一个客户程序，并立即重启该客户程序，则新的客户程序将不再重用相同的本地端口，而是使用新的端口，这不会带来什么问题，因为客户端使用本地端口，而并不关心这个端口是多少。但对于服务器来说，情况就不同了，服务器总是用我们熟知的端口，那么在2MSL时间内，重启服务器就会出错，为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。
IP协议、ARP协议、RARP协议 IP是TCP/IP协议族中最核心的协议，所有的TCP、UDP、ICMP、IGMP数据都以IP数据报的格式传输。IP仅提供尽力而为的传输服务，如果发生某种错误，IP会丢失该数据，然后发送ICMP消息给信源端。另外，IP数据报可以不按发送顺序接受。
文章图片
? 前20字节和紧接其后的选项部分是IP数据报的首部，前20个字节是固定的，选项可有可无。首部的每一行是一个32位字的单位，最高位在左边，为0bit，最低位在右边，为31bit。4字节的32bit值按照以下次序传输：首先0-7bit，其次8-15比特，然后16-23bit，最后是24-31bit，这种传输次序称为big endian字节序（我们在C语言写位操作的算法时常用到该词）。
? TCP/IP首部中的所有二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序，其他形式存储的二进制数据，如little endian格式，则必须在传输数据之前把首部转化成网络字节序。
? 首部长度是指首部占32bit字的数目，因为4位的最大值为15，因此首部最长为60字节，也即是说选项部分的最大值为40字节，不够4的倍数，要用0填充，使数据部分的起始地址为4的倍数。
【tcp/ip|TCP、IP 、HTTP——深入学习TCP协议】? 总长度指整个IP数据报的长度，包括首部和数据部分，16bit，最长可达65535字节。尽管理论上可以传送一个长达65535的IP数据报，但实际上还要考虑网络的最大承载能力等因素，标准的TCP/IP分组大小为576字节，减去IP首部的20个字节，TCP首部的20个字节，路由协议头的24个字节，为512字节，因此主机接受的数据报的数据部分一般不超过512个字节。（PS：这点看的也不是太懂，网上很多人也有此疑问，谢希仁的计算机网络中写的一次IP数据报最少576字节，尼玛这里翻译的是不超过576字节，先往后看吧，说不定看到后面就豁然开朗了）。
? 很多基于UDP协议的应用之所以要求UDP的数据部分不超过512个字节（576-20-20），主要是考虑整个传输路径上的效率，因为链路层为X2.5的网络的MTU为576个字节，这基本也是各种链路层网络的最小MTU，大于这个值就不会产生分片，之所以建议不超过这个值应该是考虑到网络承载能力和传输效率、每台主机的接受能力等很多因素的权衡。当然书上也说，576只是建议值，实际上大于它也是可以的，只是这样在遇到X2.5网络时可能产生分片。暂时是这么理解的，不知道看到后面会不会有新的收获。
IP路由选择
主机通过路由器和目的主机连接。主机通过IP数据报连接目的主机时，按照如下步骤搜索（同一网络中的搜索要经过ARP协议将目的主机的IP地址解析为MAC地址）：
搜索路由表，优先搜索匹配主机，如果能找到和IP地址完全一致的目标主机，则将该包发向目标主机
搜索路由表，如果匹配主机失败，则匹配同子网的路由器，这需要子网掩码的协助。如果找到路由器，则将该包发向路由器。
搜索路由表，如果匹配同子网路由器失败，则匹配同网号路由器，如果找到路由器，则将该包发向路由器。
搜索路由表，如果以上都失败了，就搜索默认路由，如果默认路由存在，则发包。
如果都失败了，就丢掉这个包。
子网掩码
主机号再分成一个子网号和主机号，便将一个网络又划分成了若干子网，子网掩码与该子网中的IP地址相与，便得到该子网，另外，子网对于子网内部的路由器是不透明的，也就是说IP数据报传到该网络的网关时，网关再将该数据报传送到子网的默认路由器上，最后通过该路由器再交付给该主机。
ARP协议和RARP协议
ARP协议只用在局域网中，它用来将IP地址解析为MAC地址。局域网中的每个主机都有一个ARP缓存，它保存了最近发起的IP地址到MAC地址的映射记录，当该主机要向局域网中的某一主机发送数据时，它会先从自己的缓存中查找，看是否存在目标IP地址，如果找到，就通过映射找到它的MAC地址，从而发送过去，如果没有找到该目的IP地址，它就向该局域网内发送一个广播，广播中包含自己的IP地址、MAC地址和目的主机的IP地址，局域网内的所有主机都会收到该广播，但只有目的IP地址的主机会做出回应，并把自己的MAC地址发送给源主机，源主机收到后，在自己的ARP缓存中增加上该映射，并根据发来的MAC地址将数据发送给目的主机。
ARP高速缓存中的表项一般都要设置超时值，如果一段时间内没有与某主机通信，就将该主机对应的IP与MAC之间的映射关系去掉，下次在需要通信时，依然发送广播。
如果ARP请求是从一个网络的主机到另一个网络的主机，那么连接这两个网络的路由器就可以回答该请求，这个过程成为ARP代理。
RARP协议则刚好相反，它将MAC地址解析成为对应的IP地址，通常在DHCP中有集成，现在已很少单独使用。
TCP分段与IP分片 ? 我们在学习TCP/IP协议时都知道，TCP报文段如果很长的话，会在发送时发生分段，在接受时进行重组，同样IP数据报在长度超过一定值时也会发生分片，在接收端再将分片重组。
MTU（最大传输单元）
MTU前面已经说过了，是链路层中的网络对数据帧的一个限制，依然以以太网为例，MTU为1500个字节。一个IP数据报在以太网中传输，如果它的长度大于该MTU值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的IP数据报不一定按序到达，但IP首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。
MSS（最大分段大小）
MSS是TCP里的一个概念（首部的选项字段中）。**MSS是TCP数据包每次能够传输的最大数据分段，TCP报文段的长度大于MSS时，要进行分段传输。**TCP协议在建立连接的时候通常要协商双方的MSS值，每一方都有用于通告它期望接收的MSS选项（MSS选项只出现在SYN报文段中，即TCP三次握手的前两次）。MSS的值一般为MTU值减去两个首部大小（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以如果用链路层以太网，MSS的值往往为1460。而Internet上标准的MTU（最小的MTU，链路层网络为x2.5时）为576，那么如果不设置，则MSS的默认值就为536个字节。很多时候，MSS的值最好取512的倍数。TCP报文段的分段与重组是在运输层完成的。
到了这里有一个问题自然就明了了，TCP分段的原因是MSS，IP分片的原因是MTU，由于一直有MSS<=MTU，很明显，分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了。因此TCP报文段很少会发生IP分片的情况。
再来看UDP数据报，由于UDP数据报不会自己进行分段，因此当长度超过了MTU时，会在网络层进行IP分片。同样，ICMP（在网络层中）同样会出现IP分片情况。
总结：UDP不会分段，就由IP来分。TCP会分段，当然就不用IP来分了！
另外，IP数据报分片后，只有第一片带有UDP首部或ICMP首部，其余的分片只有IP头部，到了端点后根据IP头部中的信息再网络层进行重组。而TCP报文段的每个分段中都有TCP首部，到了端点后根据TCP首部的信息在传输层进行重组。IP数据报分片后，只有到达目的地后才进行重组，而不是向其他网络协议，在下一站就要进行重组。
最后一点，对IP分片的数据报来说，即使只丢失一片数据也要重新传整个数据报（既然有重传，说明运输层使用的是具有重传功能的协议，如TCP协议）。这是因为IP层本身没有超时重传机制------由更高层（比如TCP）来负责超时和重传。当来自TCP报文段的某一段（在IP数据报的某一片中）丢失后，TCP在超时后会重发整个TCP报文段，该报文段对应于一份IP数据报（可能有多个IP分片），没有办法只重传数据报中的一个数据分片。
TCP的交互数据流和成块数据流 ? 建立在TCP协议上的应用层协议有很多，如FTP、HTTP、Telnet等，这些协议根据传输数据的多少可以分为两类：交互数据类型和成块数据类型。
? 交互数据类型，如：Telnet，这类协议一般只做小流量的数据交换，比如每按下一个键，要回显一些字符。
? 成块数据类型，如：FTP，这类协议需要传输的数据比较多，一般传输的数据量比较大。
交互数据流
? 针对交互性要求比较高的应用，比如Rlogin远程登录中，需要回显客户端输入的字符，每发送一个字节到服务端，并回显到客户端的过程如下：
1、客户端产生一个41bit长的报文（20字节的IP首部，20字节的TCP首部，1字节的数据），发送到服务端；
2、服务端发送过来一个40bit的确认报文；
3、服务端发送回显的字符，报文长为41bit；
4、客户端发送确认报文，报文长为40bit。
? 如果在局域网中，通常不会有什么麻烦，因为局域网一般不会出现拥塞，但在广域网中，这些小分组则会增加网络拥塞出现的可能。为了提高这类数据的发送效率和降低网络负担，TCP采用了两种策略：捎带ACK和Nagle算法。
成块数据流
? 对于一些数据吞吐量要求较高的应用，总是希望每次发送尽可能多的数据到主机，对于这类应用，TCP使用滑动窗口协议，该协议允许发送方在停止发送前和等待确认前可以连续发送多个分组，因此可以加速数据的传输。
滑动窗口 ? 滑动窗口的滑动是以字节为单位的，发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小，发送方A根据B发送来的确认连接报文中标明的窗口的大小，来确定收到确认前的最大发送数据量，如果A接收到的B发来的确认报文中标明的窗口大小为0，则停止发送数据，直到收到不为0的确认报文，再继续发送。发送窗口表示在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去，凡是已发送过的数据，在没有收到确认前都要暂时保留，以便超时重传时使用。
? 需要注意的一点是：使用TCP滑动窗口协议时，接收方不必确认每一个收到的分组，在TCP中，ACK确认是累积的，可以在接收到几个序号连续的报文段后只发送一个ACK确认报文，但累积等待的时间最长不能超过0.5秒，以防止发送端超时重传。
另外，要注意滑动窗口的三种变化：
1、窗口合拢。窗口左边沿向右边沿靠近，这种情况发生在数据被发送后收到确认时；
2、窗口张开。窗口右边沿向右移动，说明允许发送更多的数据，这种情况发生在另一端的接收进程从TCP接收缓存中读取了已经确认的数据时；
3、窗口收缩。窗口右边沿向左移动，一般很少发生，RFC也强烈不建议这么做，因为很可 能会产生一些错误，比如一些数据已经发送出去了，又要收缩窗口，不让发送这些数据。
另外，窗口的左边沿是肯定不可能左移的，如果接收到一个指示窗口左边沿向左移动的ACK，则它被认为是一个重复ACK，并被丢弃。
总结以下几点：
1、发送方不必发送一个全窗口大小的数据，一次发送一部分即可。
2、窗口的大小可以减小，但是窗口的右边沿却不能向左移动。
3、接收方在发送一个ACK前不必等待窗口被填满。
4、窗口的大小是相对于确认序号的，收到确认后的窗口的左边沿从确认序号开始。
发送接收缓冲区
本部分主要明确一下几点：
1、缓冲空间和序号空间都是有限的，并且都是循环使用的。
2、窗口大小一定不大于收发缓冲区的大小
3、发送缓冲区用来暂存发送方准备发送的TCP报文段和已发送但尚未收到确认的数据。
4、接收缓冲区用来暂按序到达但尚未被上层应用程序读取的数据合未按序到达的数据。
TCP的流量控制机制 一般来说，我们总是希望数据传输的更快一些，但如果发送方把数据发送的很快，而接收方来不及接收，这就可能造成数据的丢失。流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。
对于成块数据流，TCP利用滑动窗口机制来实现流量的控制，对于交互数据流，TCP利用捎带ACK和Nagle算法来实现流量的控制。
看下图：
文章图片
? 我们假设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。
? 从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。
? 我们考虑一种特殊情况，如果B在向A发送了零窗口报文段后不久，B的接收缓存又有了一些存储空间，于是B向A发送了一个rwnd=400的报文段，然而这个报文段在传送过程中丢失了，A就一直等待B发送非零窗口的报文通知，而B一直等待A发送数据，如果没有任何措施的话，这话死锁的局面会一直延续下去。
? 为了解决这个问题，TCP为每一个连接设有一个持续计时器(也叫坚持定时器)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口值仍未零，则收到这个报文段的一方就重新设置持续计时器，如果窗口不为零，那么死锁的僵局就被打破了。
? 糊涂窗口综合症。设想一种情况，TCP接收方的缓存已满，而应用进程一次只从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报为40字节长）。接收，发送方又发来1个字节的数据（发送方的IP数据报是41字节）。接收方发回确认，仍然将窗口设置为1个字节。这样，网络的效率很低。要解决这个问题，可让接收方等待一段时间，或者等到接收方缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小时再发送给接收端。
TCP中的四大定时器
重传定时器
? 很明显重传定时器是用来计算TCP报文段的超时重传时间的（至于超时重传时间的确定，这里涉及到一大堆的算法，书上有说，我这里不细谈了）。每发送一个报文段就会启动重传定时器，如果在定时器时间到后还没收到对该报文段的确认，就重传该报文段，并将重传定时器复位，重新计算；如果在规定时间内收到了对该报文段的确认，则撤销该报文段的重传定时器。
坚持定时器
为了解决零窗口大小通知可能导致的死锁问题。如果接收端在向发送端发送了零窗口报文段后不久，接收端的接收缓存又有了一些存储空间，于是接收端向发送端发送了一个非零窗口大小的报文段，然而这个报文段在传送过程中丢失了，发送端没有收到该报文段，就一直等待接收端发送非零窗口的报文通知，而接收端并不知道报文段丢失了，而是觉得已经告诉发送端了，就会一直等待发送端发送数据，如果没有任何措施的话，这话死锁的局面会一直延续下去。
为了解决这个问题，TCP为每一个连接设有一个坚持定时器(也叫持续计数器)。只要TCP连接的一方收到对方的零窗口通知，就启动坚持定时器。若坚持定时器设置的时间到期，就发送一个零窗口控测报文段（该报文段只有一个字节的数据，它有一个序号，但该序号永远不需要确认，因此该序号可以持续重传），之后会出现以下三种情况：
1、对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口值仍未零，则收到这个报文段的一方将坚持定时器的值加倍并重启。坚持计数器最大只能增加到约60秒，在此之后，每次收到零窗口通知，坚持计数器的值就定位60秒。
2、对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口不为零，那么死锁的僵局就被打破了。
3、该探测报文发出后，会同时启动重传定时器，如果重传定时器的时间到期，还没有收到接收到发来的响应，则超时重传探测报文。
保活定时器
保活定时器是为了应对两个TCP连接间出现长时间的没有数据传输的情况。如果客户已与服务器建立了TCP连接，但后来客户端主机突然故障，则服务器就不能再收到客户端发来的数据了，而服务器肯定不能这样永久地等下去，保活定时器就是用来解决这个问题的。服务器每收到一次客户端的数据，就重新设置保活定时器，通常为2小时，如果2小时没有收到客户端的数据，服务端就发送一个探测报文，以后每隔75秒发送一次，如果连续发送10次探测报文段后仍没有收到客户端的响应，服务器就认为客户端出现了故障，就可以终止这个连接。
2MSL定时器
2MSL定时器测量一个连接处于TIME—WAIT黄台的时间，通常为2MSL（报文段寿命的两倍）。2MSL定时器的设置主要是为了确保发送的最后一个ACK报文段能够到达对方，并防止之前与本连接有关的由于延迟等原因而导致已失效的报文被误判为有效。
TCP的拥塞控制机制
慢开始和拥塞避免
发送方维持一个拥塞窗口的状态变量，其大小取决于网络的拥塞程度，动态地变化，而发送窗口一般取拥塞窗口和对方给出的接收窗口的最小值（为了便于描述，后面的分析中假定对方给出的接收窗口足够大，这样将发送窗口等于拥塞窗口就可以了）。
慢开始算法的核心是从小到大逐渐增大发送窗口，也就是说，从小到大逐渐增大拥塞窗口的数值。通常在刚开始发送报文段时，先把拥塞窗口设置为一个最大报文段MSS的数值，而在每收到对上一轮报文段（，每次加倍后的报文段的个数，可能不止一个报文段）的确认后，就把拥塞窗口的数值加倍。
为了防止拥塞窗口增长过大引起网络拥塞，还需要维护一个慢开始门限的状态变量，当拥塞窗口的值小于慢开始门限时，使用慢开始算法，一旦拥塞窗口的值大于慢开始门限的值，就改用拥塞避免算法。
拥塞避免算法的思路是让拥塞窗口缓慢地增大，收到每一轮的确认后，将拥塞窗口的值加1，而不是加倍，这样拥塞窗口的值按照线性规律缓慢增长。
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（没有按时收到确认），就把慢开始门限设置为出现拥塞时发送窗口值的一般，但最小不能小于2个MSS值，而后把拥塞窗口的值重新设置为1个MSS，执行慢开始算法。
快重传和快恢复
快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（重复发送对前面有序部分的确认），而不是等待自己发送数据时才进行稍待确认，也不是累积收到的报文发送累积确认，如果发送方连续收到三个重复确认，就应该立即重传对方未收到的报文段（有收到重复确认，说明后面的报文段都送达了，只有中间丢失的报文段没送达）。
快恢复算法与快重传算法配合使用，其过程有如下两个要点：
1、当发送方连续收到三个重复确认时，就把慢开始门限减半，这是为了预防网络发生拥塞。注意，接下来不执行慢开始算法。
2、由于发送方现在认为网络很很可能没有发生特别严重的阻塞（如果发生了严重阻塞的话，就不会一连有好几个报文段到达接收方，就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口的值不设为1个MSS），而是把拥塞窗口的值设为慢开始门限减半后的值，而后开始执行拥塞避免算法，线性地增大拥塞窗口。
推荐阅读
- 链表|实现链表创建、插入、查询、反转、销毁功能
- JAVA|【Java学习】网络编程全总结——TCP、Udp、多线程、IO流、Socket、简易在线咨询聊天室、Java爬虫
- Java学习|基于TCP协议实现两人随意聊天——网络编程
- 网络安全|ARP协议
- C++|C++ 网络套接字编程TCP和UDP实例
- C++|网络套接字编程
- 计算机网络|计算机网络之IP
- #|有了 IP 地址，为什么还要用 MAC 地址（）
- ip代理|什么是IP地址冲突（如何解决IP地址冲突？）