如何理解tcp连接(TCP连接数量如何确定)

unix的哲学是一切皆文件，可以把socket看成是一种特殊的文件，而一些socket函数就是对其进行的操作api（读/写IO、打开、关闭）。我们知道普通文件的打开操作（open）返回一个文件描述字，与之类似，socket()用于创建一个socket描述符（socket descriptor），它唯一标识一个socket。当我们调用socket创建一个socket时，返回的socket描述字它存在于协议族（address family，AF_XXX）空间中，但没有一个具体的地址。如果想要给它赋值一个地址，就必须调用bind()函数，sockfd即socket描述字，它是通过socket()函数创建了，唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。在将一个地址绑定到socket的时候，需要先将主机字节序转换成为网络字节序，而不要假定主机字节序跟网络字节序一样使用的是Big-Endian。由于这个问题曾引发过不少血案，谨记对主机字节序不要做任何假定，务必将其转化为网络字节序再赋给socket。这里的主机字节序就是我们平常说的大端和小端模式：不同的CPU有不同的字节序类型，这些字节序是指整数在内存中保存的顺序，这个叫做主机序。引用标准的Big-Endian和Little-Endian的定义如下：listen函数的第一个参数即为要监听的socket描述字，第二个参数为socket可以接受的排队的最大连接个数。listen函数表示等待客户的连接请求。connect函数的第一个参数即为客户端的socket描述字，第二参数为服务器的socket地址，第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。TCP服务器端依次调用socket()、bind()、listen()之后，就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就向TCP服务器发送连接请求。TCP服务器监听到这个请求之后，就会调用accept()函数去接收请求，这样连接就建立好了(在connect之后就建立好了三次连接)，之后就可以开始进行类似于普通文件的网络I/O操作了。如果accpet成功，那么其返回值是由内核自动生成的一个全新的描述字，代表与客户的TCP连接。accept的第一个参数为服务器的socket描述字，是服务器开始调用socket()函数生成的，称为监听socket描述字；而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字，它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字，当服务器完成了对某个客户的服务，相应的已连接socket描述字就被关闭。read函数是负责从fd中读取内容.当读成功时，read返回实际所读的字节数，如果返回的值是0表示已经读到文件的结束了，小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的，如果是ECONNREST表示网络连接出了问题。write函数将buf中的nbytes字节内容写入文件描述符fd.成功时返回写的字节数。失败时返回-1，并设置errno变量。 在网络程序中，当我们向套接字文件描述符写时有俩种可能。1)write的返回值大于0，表示写了部分或者是全部的数据。2)返回的值小于0，此时出现了错误在服务器与客户端建立连接之后，会进行一些读写操作，完成了读写操作就要关闭相应的socket描述字，类似于操作完打开的文件要调用fclose关闭打开的文件。close一个TCP socket的缺省行为时把该socket标记为已关闭，然后立即返回到调用进程。该描述字不能再由调用进程使用，也就是说不能再作为read或write的第一个参数close操作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求。我们知道tcp建立连接要进行“三次握手”，即交换三个分组。大致流程如下：客户端向服务器发送一个SYN J服务器向客户端响应一个SYN K，并对SYN J进行确认ACK J+1客户端再想服务器发一个确认ACK K+1socket中TCP的四次握手释放连接详解某个应用进程首先调用close主动关闭连接，这时TCP发送一个FIN M；另一端接收到FIN M之后，执行被动关闭，对这个FIN进行确认。一段时间之后，服务端调用close关闭它的socket。这导致它的TCP也发送一个FIN N；接收到这个FIN的源发送端TCP对它进行确认,这样每个方向上都有一个FIN和ACK。为什么要三次握手由于tcp连接是全双工的，存在着双向的读写通道，每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就可以发送一个FIN来终止这个方向的连接。收到FIN只意味着这个方向上没有数据流动，但并不表示在另一个方向上没有读写，所以要双向的读写关闭需要四次握手，3. time_wait状态如何避免？首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。1.客户端连接服务器的80服务，这时客户端会启用一个本地的端口访问服务器的80，访问完成后关闭此连接，立刻再次访问服务器的80，这时客户端会启用另一个本地的端口，而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。2.客户端连接服务器的80服务，这时服务器关闭80端口，立即再次重启80端口的服务，这时可能不会成功启动，原因也是服务器的连接还处于TIME_WAIT状态。实战分析：状态描述：CLOSED：无连接是活动的或正在进行LISTEN：服务器在等待进入呼叫SYN_RECV：一个连接请求已经到达，等待确认SYN_SENT：应用已经开始，打开一个连接ESTABLISHED：正常数据传输状态FIN_WAIT1：应用说它已经完成FIN_WAIT2：另一边已同意释放ITMED_WAIT：等待所有分组死掉CLOSING：两边同时尝试关闭TIME_WAIT：另一边已初始化一个释放LAST_ACK：等待所有分组死掉命令解释：如何尽量处理TIMEWAIT过多?编辑内核文件/etc/sysctl.conf，加入以下内容：net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间然后执行 /sbin/sysctl -p 让参数生效./etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口，它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，修改内核参数永久生效。简单来说，就是打开系统的TIMEWAIT重用和快速回收。本文主要讲述了socket的主要api，以及tcp的连接过程和其中各个阶段的连接状态，理解这些是更深入了解tcp的基础！

为什么要有三次握手，因为如果只有两次握手，那么第一次：客户端发送一个syn包给服务器，里面有一个随机生成的syn，然后客户端处于syn_send状态第二次：服务端收到客户端发来的syn包之后，确认syn包，也就是生成一个ack=syn+1，然后再自己随机生成一个syn包，即syn+ack包，然后返回给客户端，自己变成syn_recv状态第三次：客户端收到服务端发来的syn+ack包之后，确认ack是正确的之后，返回一个ack=syn+1给服务端，此包发送完毕，客户端进入了ESTABLISHED状态，服务端收到ack包后也进入ESTABLISHED状态。SYN攻击，当第二次握手服务端发送了syn+ack包之后，收到客户端发送的ack之前这段时间的tcp链接成为半连接，此时服务端处于syn_recv状态。当大量客户端随机IP疯狂发送tcp链接请求时，客户端以为是不同用户的请求，所以队列中全是半连接，然后导致服务器宕机，正常请求被丢弃。第一个包发送过程丢失A会周期性超时重传，直到收到B的确认第二个包发送过程丢失B会周期性超时重传，直到收到A的确认第三个包发送过程丢失A发送完数据后单方面进入TCP的ESTABLISHED状态，B还处于半链接：TCP协议为什么需要三次握手？第一次：客户端发送一个fin给服务端表示自己要断开连接了，然后进入fin_wait_1状态第二次：服务端收到fin后，发送一个ack=fin+1给客户端，服务端进入close_wait状态，客户端进入fin_wait_2状态第三次：服务端发送一个fin，用来关闭服务端到客户端的数据传输，服务端进入last_ack状态第四次：客户端收到fin后，进入time_wait状态，然后发送一个ack=fin+1给服务端，服务端确认后进入close状态，完成四次挥手TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。答案解析：浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。在 HTTP/1.0 中，一个http请求收到服务器响应后，会断开对应的TCP连接。这样每次请求，都需要重新建立TCP连接，这样一直重复建立和断开的过程，比较耗时。所以为了充分利用TCP连接，可以设置头字段 Connection: keep-alive ，这样http请求完成后，就不会断开当前的TCP连接，后续的http请求可以使用当前TCP连接进行通信。第一次访问有初始化连接和SSL开销初始化连接和SSL开销消失了，说明使用的是同一个TCP连接。HTTP/1.1 将 Connection 写入了标准，默认值为 keep-alive 。除非强制设置为 Connection: close ，才会在请求后断开TCP连接。所以这一题的答案就是：默认情况下建立的TCP连接不会断开，只有在请求头中设置 Connection: close 才会在请求后关闭TCP连接。HTTP/1.1 中，单个TCP连接，在同一时间只能处理一个http请求，虽然存在Pipelining技术支持多个请求同时发送，但由于实践中存在很多问题无法解决，所以浏览器默认是关闭，所以可以认为是不支持同时多个请求。HTTP2 提供了多路传输功能，多个http请求，可以同时在同一个TCP连接中进行传输。页面资源请求时，浏览器会同时和服务器建立多个TCP连接，在同一个TCP连接上顺序处理多个HTTP请求。所以浏览器的并发性就体现在可以建立多个TCP连接，来支持多个http同时请求。Chrome浏览器最多允许对同一个域名Host建立6个TCP连接，不同的浏览器有所区别。补充如果图片都是HTTPS的连接，并且在同一域名下，浏览器会先和服务器协商使用 HTTP2 的 Multiplexing 功能进行多路传输，不过未必所有的挂在这个域名下的资源都会使用同一个TCP连接。如果用不了HTTPS或者HTTP2（HTTP2是在HTTPS上实现的），那么浏览器会就在同一个host建立多个TCP连接，每一个TCP连接进行顺序请求资源。参考：[1]. 第8题-浏览器HTTP请求并发数和TCP连接的关系

转自： https://mp.weixin.qq.com/s/sNHPwyyckZZLFMLp-mURWA假如你是一台电脑，你的名字叫 A经过 《如果让你来设计网络，你会把它弄成啥样？》 这篇文章中的一番折腾，只要你知道另一位伙伴 B 的 IP 地址，且你们之间的网络是通的，无论多远，你都可以将一个数据包发送给你的伙伴 B。这就是物理层、数据链路层、网络层这三层所做的事情。站在第四层的你，就可以不要脸地利用下三层所做的铺垫，随心所欲地发送数据，而不必担心找不到对方了。虽然你此时还什么都没干，但你还是给自己这一层起了个响亮的名字，叫做 传输层 。你本以为自己所在的第四层万事大吉，啥事没有，但很快问题就接踵而至。问题来了前三层协议只能把数据包从一个主机搬到另外一台主机，但是，到了目的地以后，数据包具体交给哪个 程序 （进程）呢？所以，你需要把通信的进程区分开来，于是就给每个进程分配一个数字编号，你给它起了一个响亮的名字： 端口号 。然后你在要发送的数据包上，增加了传输层的头部， 源端口号 与 目标端口号 。OK，这样你将原本主机到主机的通信，升级为了 进程和进程之间的通信 。你没有意识到，你不知不觉实现了  UDP 协议 ！（当然 UDP 协议中不光有源端口和目标端口，还有数据包长度和校验值，我们暂且略过）就这样，你用 UDP 协议无忧无虑地同 B 进行着通信，一直没发生什么问题。但很快，你发现事情变得非常复杂......丢包问题由于网络的不可靠，数据包可能在半路丢失，而 A 和 B 却无法察觉。对于丢包问题，只要解决两个事就好了。第一个，A 怎么知道包丢了？答案：让 B 告诉 A第二个，丢了的包怎么办？答案：重传于是你设计了如下方案，A 每发一个包，都必须收到来自 B 的 确认 （ACK），再发下一个，否则在一定时间内没有收到确认，就 重传 这个包。你管它叫 停止等待协议 。只要按照这个协议来，虽然 A 无法保证 B 一定能收到包，但 A 能够确认 B 是否收到了包，收不到就重试，尽最大努力让这个通信过程变得可靠，于是你们现在的通信过程又有了一个新的特征， 可靠交付 。停止等待虽然能解决问题，但是效率太低了，A 原本可以在发完第一个数据包之后立刻开始发第二个数据包，但由于停止等待协议，A 必须等数据包到达了 B ，且 B 的 ACK 包又回到了 A，才可以继续发第二个数据包，这效率慢得可不是一点两点。于是你对这个过程进行了改进，采用 流水线 的方式，不再傻傻地等。但是网路是复杂的、不可靠的。有的时候 A 发出去的数据包，分别走了不同的路由到达 B，可能无法保证和发送数据包时一样的顺序。在流水线中有多个数据包和ACK包在 乱序流动 ，他们之间对应关系就乱掉了。难道还回到停止等待协议？A 每收到一个包的确认（ACK）再发下一个包，那就根本不存在顺序问题。应该有更好的办法！A 在发送的数据包中增加一个 序号 （seq），同时 B 要在 ACK 包上增加一个 确认号 （ack），这样不但解决了停止等待协议的效率问题，也通过这样标序号的方式解决了顺序问题。而 B 这个确认号意味深长：比如 B 发了一个确认号为 ack = 3，它不仅仅表示 A 发送的序号为 2 的包收到了，还表示 2 之前的数据包都收到了。这种方式叫 累计确认 或 累计应答 。注意，实际上 ack 的号是收到的最后一个数据包的序号 seq + 1，也就是告诉对方下一个应该发的序号是多少。但图中为了便于理解，ack 就表示收到的那个序号，不必纠结。有的时候，A 发送数据包的速度太快，而 B 的接收能力不够，但 B 却没有告知 A 这个情况。怎么解决呢？很简单，B 告诉 A 自己的接收能力，A 根据 B 的接收能力，相应控制自己的 发送速率 ，就好了。B 怎么告诉 A 呢？B 跟 A 说"我很强"这三个字么？那肯定不行，得有一个严谨的规范。于是 B 决定，每次发送数据包给 A 时，顺带传过来一个值，叫 窗口大小 （win)，这个值就表示 B 的 接收能力 。同理，每次 A 给 B 发包时也带上自己的窗口大小，表示 A 的接收能力。B 告诉了 A 自己的窗口大小值，A 怎么利用它去做 A 这边发包的流量控制呢？很简单，假如 B 给 A 传过来的窗口大小 win = 5，那 A 根据这个值，把自己要发送的数据分成这么几类。图片过于清晰，就不再文字解释了。当 A 不断发送数据包时， 已发送的最后一个序号 就往右移动，直到碰到了窗口的上边界，此时 A 就无法继续发包，达到了流量控制。但是当 A 不断发包的同时，A 也会收到来自 B 的确认包，此时 整个窗口 会往右移动，因此上边界也往右移动，A 就能发更多的数据包了。以上都是在窗口大小不变的情况下，而 B 在发给 A 的 ACK 包中，每一个都可以 重新设置 一个新的窗口大小，如果 A 收到了一个新的窗口大小值，A 会随之调整。如果 A 收到了比原窗口值更大的窗口大小，比如 win = 6，则 A 会直接将窗口上边界向右移动 1 个单位。如果 A 收到了比原窗口值小的窗口大小，比如 win = 4，则 A 暂时不会改变窗口大小，更不会将窗口上边界向左移动，而是等着 ACK 的到来，不断将左边界向右移动，直到窗口大小值收缩到新大小为止。OK，终于将流量控制问题解决得差不多了，你看着上面一个个小动图，给这个窗口起了一个更生动的名字， 滑动窗口 。但有的时候，不是 B 的接受能力不够，而是网络不太好，造成了 网络拥塞 。拥塞控制与流量控制有些像，但流量控制是受 B 的接收能力影响，而拥塞控制是受 网络环境 的影响。拥塞控制的解决办法依然是通过设置一定的窗口大小，只不过，流量控制的窗口大小是 B 直接告诉 A 的，而拥塞控制的窗口大小按理说就应该是网络环境主动告诉 A。但网络环境怎么可能主动告诉 A 呢？只能 A 单方面通过 试探 ，不断感知网络环境的好坏，进而确定自己的拥塞窗口的大小。拥塞窗口大小的计算有很多复杂的算法，就不在本文中展开了，假如 拥塞窗口的大小为  cwnd ，上一部分流量控制的 滑动窗口的大小为 rwnd ，那么窗口的右边界受这两个值共同的影响，需要取它俩的最小值。窗口大小 = min(cwnd, rwnd)含义很容易理解，当 B 的接受能力比较差时，即使网络非常通畅，A 也需要根据 B 的接收能力限制自己的发送窗口。当网络环境比较差时，即使 B 有很强的接收能力，A 也要根据网络的拥塞情况来限制自己的发送窗口。正所谓受其 短板 的影响嘛~有的时候，B 主机的相应进程还没有准备好或是挂掉了，A 就开始发送数据包，导致了浪费。这个问题在于，A 在跟 B 通信之前，没有事先确认 B 是否已经准备好，就开始发了一连串的信息。就好比你和另一个人打电话，你还没有"喂"一下确认对方有没有在听，你就巴拉巴拉说了一堆。这个问题该怎么解决呢？地球人都知道， 三次握手 嘛！A：我准备好了(SYN)B：我知道了(ACK)，我也准备好了(SYN)A：我知道了(ACK)A 与 B 各自在内存中维护着自己的状态变量，三次握手之后，双方的状态都变成了 连接已建立 （ESTABLISHED）。虽然就只是发了三次数据包，并且在各自的内存中维护了状态变量，但这么说总觉得太 low，你看这个过程相当于双方建立连接的过程，于是你灵机一动，就叫它 面向连接 吧。注意：这个连接是虚拟的，是由 A 和 B 这两个终端共同维护的，在网络中的设备根本就不知道连接这回事儿！但凡事有始就有终，有了建立连接的过程，就要考虑释放连接的过程，又是地球人都知道， 四次挥手 嘛！A：再见，我要关闭了(FIN)B：我知道了(ACK)给 B 一段时间把自己的事情处理完...B：再见，我要关闭了(FIN)A：我知道了(ACK)以上讲述的，就是 TCP 协议的核心思想，上面过程中需要传输的信息，就体现在 TCP 协议的头部，这里放上最常见的 TCP 协议头解读的图。不知道你现在再看下面这句话，是否能理解：TCP 是面向连接的、可靠的、基于字节流的传输层通信协议面向连接、可靠，这两个词通过上面的讲述很容易理解，那什么叫做基于字节流呢？很简单，TCP 在建立连接时，需要告诉对方 MSS（最大报文段大小）。也就是说，如果要发送的数据很大，在 TCP 层是需要按照 MSS 来切割成一个个的  TCP 报文段  的。切割的时候我才不管你原来的数据表示什么意思，需要在哪里断句啥的，我就把它当成一串毫无意义的字节，在我想要切割的地方咔嚓就来一刀，标上序号，只要接收方再根据这个序号拼成最终想要的完整数据就行了。在我 TCP 传输这里，我就把它当做一个个的 字节 ，也就是基于字节流的含义了。一提到 TCP，可能很多人都想起被三次握手和四次挥手所支配的恐惧。但其实你跟着文中的思路你就会发现，三次握手与四次挥手只占 TCP 所解决的核心问题中很小的一部分，只是因为它在面试中很适合作为知识点进行考察，所以在很多人的印象中就好像 TCP 的核心就是握手和挥手似的。 如果你能从问题出发，真正理解 TCP 所想要解决的问题，你会发现很多原理就好像生活常识一样顺其自然，并不复杂，希望你读完本文能有所收获～

如果你在学习这门课程，仅仅为了理解网络工作原理，那么只要了解TCP是可靠传输，数据传输丢失时会重传就可以了。如果你还要参加研究生考试或者公司面试等，那么下面内容很有可能成为考查的知识点，主要的重点是序号/确认号的编码、超时定时器的设置、可靠传输和连接的管理。 1 TCP连接TCP面向连接，在一个应用进程开始向另一个应用进程发送数据之前，这两个进程必须先相互“握手”，即它们必须相互发送某些预备报文段，以建立连接。连接的实质是双方都初始化与连接相关的发送/接收缓冲区，以及许多TCP状态变量。这种“连接”不是一条如电话网络中端到端的电路，因为它们的状态完全保留在两个端系统中。TCP连接提供的是全双工服务 ，应用层数据就可在从进程B流向进程A的同时，也从进程A流向进程B。TCP连接也总是点对点的 ，即在单个发送方与单个接收方之间建立连接。一个客户机进程向服务器进程发送数据时，客户机进程通过套接字传递数据流。客户机操作系统中运行的 TCP软件模块首先将这些数据放到该连接的发送缓存里 ，然后会不时地从发送缓存里取出一块数据发送。TCP可从缓存中取出并放入报文段中发送的数据量受限于最大报文段长MSS，通常由最大链路层帧长度来决定(也就是底层的通信链路决定)。 例如一个链路层帧的最大长度1500字节，除去数据报头部长度20字节，TCP报文段的头部长度20字节，MSS为1460字节。报文段被往下传给网络层，网络层将其封装在网络层IP数据报中。然后这些数据报被发送到网络中。当TCP在另一端接收到一个报文段后，该报文段的数据就被放人该连接的接收缓存中。应用程序从接收缓存中读取数据流(注意是应用程序来读，不是操作系统推送)。TCP连接的每一端都有各自的发送缓存和接收缓存。因此TCP连接的组成包括:主机上的缓存、控制变量和与一个进程连接的套接字变量名，以及另一台主机上的一套缓存、控制变量和与一个进程连接的套接字。在这两台主机之间的路由器、交换机中，没有为该连接分配任何缓存和控制变量。2报文段结构TCP报文段由首部字段和一个数据字段组成。数据字段包含有应用层数据。由于MSS限制了报文段数据字段的最大长度。当TCP发送一个大文件时，TCP通常是将文件划分成长度为MSS的若干块。TCP报文段的结构。首部包括源端口号和目的端口号，它用于多路复用/多路分解来自或送至上层应用的数据。另外，TCP首部也包括校验和字段。报文段首部还包含下列字段:32比特的序号字段和32比特的确认号字段。这些字段被TCP发送方和接收方用来实现可靠数据传输服务。16比特的接收窗口字段，该字段用于流量控制。该字段用于指示接收方能够接受的字节数量。4比特的首部长度字段,该字段指示以32比特的字为单位的TCP首部长度。一般TCP首部的长度就是20字节。可选与变长的选项字段,该字段用于当发送方与接收方协商最大报文段长度，或在高速网络环境下用作窗口调节因子时使用。标志字段ACK比特用于指示确认字段中的ACK值的有效性，即该报文段包括一个对已被成功接收报文段的确认。 SYN和FIN比特用于连接建立和拆除。 PSH、URG和紧急指针字段通常没有使用。•序号和确认号TCP报文段首部两个最重要的字段是序号字段和确认号字段。TCP把数据看成一个无结构的但是有序的字节流。TCP序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。一个报文段的序号是该报文段首字节在字节流中的编号。例如，假设主机A上的一个进程想通过一条TCP连接向主机B上的一个进程发送一个数据流。主机A中的TCP将对数据流中的每一个字节进行编号。假定数据流由一个包含4500字节的文件组成(可以理解为应用程序调用send函数传递过来的数据长度)，MSS为1000字节(链路层一次能够传输的字节数)，如果主机决定数据流的首字节编号是7。TCP模块将为该数据流构建5个报文段(也就是分5个IP数据报)。第一个报文段的序号被赋为7;第二个报文段的序号被赋为1007,第三个报文段的序号被赋为2007，以此类推。前面4个报文段的长度是1000，最后一个是500。确认号要比序号难理解一些。前面讲过，TCP是全双工的，因此主机A在向主机B发送数据的同时，也可能接收来自主机B的数据。从主机B到达的每个报文段中的序号字段包含了从B流向A的数据的起始位置。 因此主机B填充进报文段的确认号是主机B期望从主机A收到的下一报文段首字节的序号。假设主机B已收到了来自主机A编号为7-1006的所有字节，同时假设它要发送一个报文段给主机A。主机B等待主机A的数据流中字节1007及后续所有字节。所以，主机B会在它发往主机A的报文段的确认号字段中填上1007。再举一个例子，假设主机B已收到一个来自主机A的包含字节7-1006的报文段，以及另一个包含字节2007-3006的报文段。由于某种原因，主机A还没有收到字节1007-2006的报文段。在这个例子中，主机A为了重组主机B的数据流，仍在等待字节1007。因此，A在收到包含字节2007-3006的报文段时，将会又一次在确认号字段中包含1007。 因为TCP只确认数据流中至第一个丢失报文段之前的字节数据，所以TCP被称为是采用累积确认。TCP的实现有两个基本的选择:1接收方立即丢弃失序报文段;2接收方保留失序的字节，并等待缺少的字节以填补该间隔。一条TCP连接的双方均可随机地选择初始序号。 这样做可以减少将那些仍在网络中的来自两台主机之间先前连接的报文段，误认为是新建连接所产生的有效报文段的可能性。•例子telnetTelnet由是一个用于远程登录的应用层协议。它运行在TCP之上，被设计成可在任意一对主机之间工作。假设主机A发起一个与主机B的Telnet会话。因为是主机A发起该会话，因此主机A被标记为客户机，主机B被标记为服务器。用户键入的每个字符(在客户机端)都会被发送至远程主机。远程主机收到后会复制一个相同的字符发回客户机，并显示在Telnet用户的屏幕上。这种“回显”用于确保由用户发送的字符已经被远程主机收到并处理。因此，在从用户击键到字符显示在用户屏幕上之间的这段时间内，每个字符在网络中传输了两次。现在假设用户输入了一个字符“C”，假设客户机和服务器的起始序号分别是42和79。前面讲过，一个报文段的序号就是该报文段数据字段首字节的序号。因此，客户机发送的第一个报文段的序号为42，服务器发送的第一个报文段的序号为79。前面讲过，确认号就是主机期待的数据的下一个字节序号。在TCP连接建立后但没有发送任何数据之前，客户机等待字节79，而服务器等待字节42。如图所示，共发了3个报文段。第一个报文段是由客户机发往服务器，其数据字段里包含一字节的字符“C”的ASCII码，其序号字段里是42。另外，由于客户机还没有接收到来自服务器的任何数据，因此该报文段中的确认号字段里是79。第二个报文段是由服务器发往客户机。它有两个目的:第一个目的是为服务器所收到的数据提供确认。服务器通过在确认号字段中填入43，告诉客户机它已经成功地收到字节42及以前的所有字节，现在正等待着字节43的出现。第二个目的是回显字符“C”。因此，在第二个报文段的数据字段里填入的是字符“C”的ASCII码，第二个报文段的序号为79，它是该TCP连接上从服务器到客户机的数据流的起始序号，也是服务器要发送的第一个字节的数据。这里客户机到服务器的数据的确认被装载在一个服务器到客户机的数据的报文段中，这种确认被称为是捎带确认.第三个报文段是从客户机发往服务器的。它的唯一目的是确认已从服务器收到的数据。3往返时延的估计与超时TCP如同前面所讲的rdt协议一样，采用超时/重传机制来处理报文段的丢失问题。最重要的一个问题就是超时间隔长度的设置。显然，超时间隔必须大于TCP连接的往返时延RTT，即从一个报文段发出到收到其确认时。否则会造成不必要的重传。•估计往返时延TCP估计发送方与接收方之间的往返时延是通过采集报文段的样本RTT来实现的，就是从某报文段被发出到对该报文段的确认被收到之间的时间长度。也就是说TCP为一个已发送的但目前尚未被确认的报文段估计sampleRTT，从而产生一个接近每个RTT的采样值。但是，TCP不会为重传的报文段计算RTT。为了估计一个典型的RTT，采取了某种对RTT取平均值的办法。TCP据下列公式来更新EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT即估计RTT的新值是由以前估计的RTT值与sampleRTT新值加权组合而成的。参考值是a=0.125，因此是一个加权平均值。显然这个加权平均对最新样本赋予的权值要大于对老样本赋予的权值。因为越新的样本能更好地反映出网络当前的拥塞情况。从统计学观点来讲，这种平均被称为指数加权移动平均除了估算RTT外，还需要测量RTT的变化，RTT偏差的程度，因为直接使用平均值设置计时器会有问题(太灵敏)。DevRTT=(1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|RTT偏差也使用了指数加权移动平均。B取值0.25.•设置和管理重传超时间隔假设已经得到了估计RTT值和RTT偏差值，那么TCP超时间隔应该用什么值呢?TCP将超时间隔设置成大于等于估计RTT值和4倍的RTT偏差值,否则将造成不必要的重传。但是超时间隔也不应该比估计RTT值大太多，否则当报文段丢失时，TCP不能很快地重传该报文段，从而将给上层应用带来很大的数据传输时延。因此，要求将超时间隔设为估计RTT值加上一定余量。当估计RTT值波动较大时，这个余最应该大些;当波动比较小时，这个余量应该小些。因此使用4倍的偏差值来设置重传时间。TimeoutInterval=EstimatedRTT+4*DevRTT4可信数据传输因特网的网络层服务是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。TCP在IP不可靠的尽力而为服务基础上建立了一种可靠数据传输服务。TCP提供可靠数据传输的方法涉及前面学过的许多原理。TCP采用流水线协议、累计确认。TCP推荐的定时器管理过程使用单一的重传定时器，即使有多个已发送但还未被确认的报文段也一样。重传由超时和多个ACK触发。在TCP发送方有3种与发送和重传有关的主要事件:从上层应用程序接收数据，定时器超时和收到确认ACK。从上层应用程序接收数据。一旦这个事件发生，TCP就从应用程序接收数据，将数据封装在一个报文段中，并将该报文段交给IP。注意到每一个报文段都包含一个序号，这个序号就是该报文段第一个数据字节的字节流编号。如果定时器还没有计时，则当报文段被传给IP时，TCP就启动一个该定时器。第二个事件是超时。TCP通过重传引起超时的报文段来响应超时事件。然后TCP重启定时器。第三个事件是一个来自接收方的确认报文段(ACK)。当该事件发生时，TCP将ACK的值y与变量SendBase(发送窗口的基地址)进行比较。TCP状态变量SendBase是最早未被确认的字节的序号。就是指接收方已正确按序接收到数据的最后一个字节的序号。TCP采用累积确认，所以y确认了字节编号在y之前的所有字节都已经收到。如果Y>SendBase,则该ACK是在确认一个或多个先前未被确认的报文段。因此发送方更新其SendBase变量，相当于发送窗口向前移动。另外，如果当前有未被确认的报文段，TCP还要重新启动定时器。快速重传超时触发重传存在的另一个问题是超时周期可能相对较长。当一个报文段丢失时，这种长超时周期迫使发送方等待很长时间才重传丢失的分组，因而增加了端到端时延。所以通常发送方可在超时事件发生之前通过观察冗余ACK来检测丢包情况。冗余ACK就是接收方再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。当TCP接收方收到一个序号比所期望的序号大的报文段时，它认为检测到了数据流中的一个间隔，即有报文段丢失。这个间隔可能是由于在网络中报文段丢失或重新排序造成的。因为TCP使用累计确认，所以接收方不向发送方发回否定确认，而是对最后一个正确接收报文段进行重复确认(即产生一个冗余ACK)如果TCP发送方接收到对相同报文段的3个冗余ACK.它就认为跟在这个已被确认过3次的报文段之后的报文段已经丢失。一旦收到3个冗余ACK，TCP就执行快速重传 ，即在该报文段的定时器过期之前重传丢失的报文段。5流量控制前面讲过，一条TCP连接双方的主机都为该连接设置了接收缓存。当该TCP连接收到正确、按序的字节后，它就将数据放入接收缓存。相关联的应用进程会从该缓存中读取数据，但没必要数据刚一到达就立即读取。事实上，接收方应用也许正忙于其他任务，甚至要过很长时间后才去读取该数据。如果应用程序读取数据时相当缓慢，而发送方发送数据太多、太快，会很容易使这个连接的接收缓存溢出。TCP为应用程序提供了流量控制服务以消除发送方导致接收方缓存溢出的可能性。因此，可以说 流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读速率相匹配。前面提到过，TCP发送方也可能因为IP网络的拥塞而被限制，这种形式的发送方的控制被称为拥塞控制(congestioncontrol)。TCP通过让接收方维护一个称为接收窗口的变量来提供流量控制。接收窗口用于告诉发送方，该接收方还有多少可用的缓存空间。因为TCP是全双工通信，在连接两端的发送方都各自维护一个接收窗口变量。 主机把当前的空闲接收缓存大小值放入它发给对方主机的报文段接收窗口字段中，通知对方它在该连接的缓存中还有多少可用空间。6 TCP连接管理客户机中的TCP会用以下方式与服务器建立一条TCP连接:第一步: 客户机端首先向服务器发送一个SNY比特被置为1报文段。该报文段中不包含应用层数据，这个特殊报文段被称为SYN报文段。另外，客户机会选择一个起始序号，并将其放置到报文段的序号字段中。为了避免某些安全性攻击，这里一般随机选择序号。第二步: 一旦包含TCP报文段的用户数据报到达服务器主机，服务器会从该数据报中提取出TCPSYN报文段，为该TCP连接分配TCP缓存和控制变量，并向客户机TCP发送允许连接的报文段。这个允许连接的报文段还是不包含应用层数据。但是，在报文段的首部却包含3个重要的信息。首先，SYN比特被置为1。其次，该 TCP报文段首部的确认号字段被置为客户端序号+1最后，服务器选择自己的初始序号，并将其放置到TCP报文段首部的序号字段中。 这个允许连接的报文段实际上表明了:“我收到了你要求建立连接的、带有初始序号的分组。我同意建立该连接，我自己的初始序号是XX”。这个同意连接的报文段通常被称为SYN+ACK报文段。第三步: 在收到SYN+ACK报文段后，客户机也要给该连接分配缓存和控制变量。客户机主机还会向服务器发送另外一个报文段，这个报文段对服务器允许连接的报文段进行了确认。因为连接已经建立了，所以该ACK比特被置为1，称为ACK报文段，可以携带数据。一旦以上3步完成，客户机和服务器就可以相互发送含有数据的报文段了。为了建立连接，在两台主机之间发送了3个分组，这种连接建立过程通常被称为 三次握手(SNY、SYN+ACK、ACK，ACK报文段可以携带数据) 。这个过程发生在客户机connect()服务器，服务器accept()客户连接的阶段。假设客户机应用程序决定要关闭该连接。(注意，服务器也能选择关闭该连接)客户机发送一个FIN比特被置为1的TCP报文段，并进人FINWAIT1状态。当处在FINWAIT1状态时，客户机TCP等待一个来自服务器的带有ACK确认信息的TCP报文段。当它收到该报文段时，客户机TCP进入FINWAIT2状态。当处在FINWAIT2状态时，客户机等待来自服务器的FIN比特被置为1的另一个报文段，收到该报文段后，客户机TCP对服务器的报文段进行ACK确认，并进入TIME_WAIT状态。TIME_WAIT状态使得TCP客户机重传最终确认报文，以防该ACK丢失。在TIME_WAIT状态中所消耗的时间是与具体实现有关的，一般是30秒或更多时间。 经过等待后，连接正式关闭，客户机端所有与连接有关的资源将被释放。 因此TCP连接的关闭需要客户端和服务器端互相交换连接关闭的FIN、ACK置位报文段。

TCP：传输、控制、协议。TCP与UDP最大却别就在那个C上面，它充分实现了数据传输时各种控制功能。可以进行丢包重发控制，还可以对次序乱掉的数据包进行顺序控制，还能控制传输流量，这些是UDP中没有的。即T C P 提供一种面向连接的、可靠的字节流服务。TCP是一中面向有链接的协议，只有在确认对端存在的时候，才会发送分数据，从而也可以控制通信流量的浪费。什么是可靠的传输：不丢包、不损坏、不乱序、不重复。TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制来实现可靠传输。接收端查询就收数据TCP首部中的序号和数据长度。将自己下一步应该接受的序列号作为确认应答返送回去。就这样，通过序列号和确认应答，TCP实现可靠传输。一般使用TCP首部用于控制的字段来管理连接。一个连接的建立和断开，正常过程中，至少需要来回共7个包才能完成。TCP首部的数据结构如图所示：TCP包首部为了便于理解，忽略选项部分，固定首部通常为20个字节，将按作用分类分析。前4个字节来标识了发送方的端口号和接收方的端口号，即该数据包由谁发送，由谁接收。前2个字节标识源端口号，紧接着2个字节标识目的端口号。即发送方：(11111111,1111111)2= (65535)10，除去0~1023.即接收方：(11111111,1111111)2= (65535)10，除去0~1023.TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号。长度为4字节，序号是32bit的无符号数,序号到达232- 1后又从0开始。ack：确认序号，即确认字节的序号，更确切地说，是发送确认的一端所期望收到的下一个序号。所谓的发送确认的一端就是将确认信息发出的一端。比如第二次握手的S端就是发送确认的一端。确认序号为上次接收的最后一个字节序号加1.只有确认标志位(ACK)为1的时候，确认序号才有效。也叫首部长度，占4个bit,它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。TCP报文结构由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。“首部长度”是4位二进制数，单位是32位字，能表示的最大十进制数字是15。(1111)2=(15)10,即是15个32位，一个32位是4个字节，因此数据偏移的最大值是154=60个字节，这也是TCP首部的最大字节。因为固定首部的存在，数据偏移的值最小为20个字节，因此选项长度不能超过40字节*（减去20个字节的固定首部）。占6位，保留为今后使用，但目前应置为0。当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快发送（相当于高优先级的数据），而不要按原来的排队顺序来传送。例如，已经发送了很长的一个程序要在远地的主机上运行。但后来发现了一些问题，需要取消该程序的运行，因此用户从键盘发出中断命令。如果不使用紧急数据，那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了很多时间。当URG置为1时，应用进程就告诉TCP有紧急数据要传送。于是TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍然是普通数据。这时要与首部中紧急指针（Urgent Pointer）字段配合使用。仅当ACK = 1时确认号字段才有效，当ACK = 0时确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1。当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下，TCP就可以使用推送（push）操作。发送方TCP把PSH置为1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地（即“推送”向前）交付接收应用进程。而不用再等到整个缓存都填满了后再向上交付。当RST=1时，表明TCP连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。RST置为1还用来拒绝一个非法的报文段或拒绝打开一个连接。在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此SYN=1就表示这是一个连接请求或连接接受报文。用来释放一个连接。当FIN=1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。占2字节。窗口值是(0，216-1)之间的整数。窗口指的是发送本报文段的一方的接受窗口（而不是自己的发送窗口）,窗口大小是给对方用的。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方一次发送的数据量（以字节为单位）。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。例如，A发送了一个报文段，其确认号是3000，窗口字段是1000.这就是告诉对方B：“从3000算起，A接收缓存空间还可接受1000个字节数据，字节序号是3000-3999”，可以想象到河道的阀门。总之：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。伪首部的格式和UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为6（TCP的协议号是6）；把第5字段中的UDP中的长度改为TCP长度。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。若使用TPv6,则相应的伪首部也要改变。占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据） 。因此，在紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时，TCP就告诉应用程序恢复到正常操作。值得注意的是，即使窗口为0时也可以发送紧急数据。长度可变，最长可达40个字节。当没有使用“选项”时，TCP的首部长度是20字节。最大报文段长度(MSS:Maximum Segment Size)表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。当建立一个连接时，每一方都有用于通告它期望接收的MSS选项(MSS选项只能出现在SYN报文段中),如果一方不接收来自另一方的MSS值，则MSS就定为默认值536字节(这个默认值允许20字节的IP首部和20字节的TCP首部以适合576字节IP数据报) 。为什么要规定一个最大报文长度MSS呢？这并不是考虑接受方的接收缓存可能存放不下TCP报文段中的数据。实际上，MSS与接收窗口值没有关系。我们知道，TCP报文段的数据部分，至少要加上40字节的首部（TCP首部20字节和IP首部20字节，这里还没有考虑首部中的可选部分）才能组装成一个IP数据报。若选择较小的MSS长度，网络的利用率就降低。设想在极端情况下，当TCP报文段只含有1字节的数据时，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，对网络的利用率就不会超过1/41。到了数据链路层还要加上一些开销。但反过来，若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片组成成原来的TCP报文段，当传输出错时还要进行重传，这些也都会使开销增大。因此，MSS应尽可能大些，只要在IP层传输时不需要分片就行。由于IP数据报所经历的路径是动态变化的，因此在这条路径上确定的不需要的分片的MSS，如果改走另一条路径就可能需要进行分片。因此最佳的MSS是很难确定的。在连接过程中，双方都把自己能够支持的MSS写入这一字段，以后就按照这个数值传输数据，两个传送方向可以有不同的MSS值。若主机未填写这一项，则MSS的默认值是536字节长。因此，所有在互联网上的主机都应该接受的报文段长度是536+20（固定首部长度）=556字节。后来又增加了几个选项如窗口扩大选项、时间戳选项等。窗口扩大选项是为了扩大窗口。我们知道，TCP首部中窗口字段长度是16位，因此最大的窗口大小为64K字节。虽然这对早期的网络是足够用的，但对于包含卫星信道的网络，传播时延和宽带都很大，要获得高吞吐量需要更大的窗口大小。窗口扩大选项占3字节，其中有一个字节表示移位值S。新的窗口值等于TCP首部中的窗口位数从16增大到（16+S）。移位值允许使用的最大值是14，相当于窗口最大值增大到2（16+14）-1=230-1。窗口扩大选项可以在双方初始建立TCP连接时进行协商。如果连接的某一端实现了窗口扩大，当它不再需要扩大其窗口时，可发送S=0选项，使窗口大小回到16。时间戳选项占10字节，其中最主要的字段是时间戳字段（4字节）和时间戳回送回答字段（4字节）。时间戳选项有以下两个概念：第一、 用来计算往返时间RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段复制到时间戳回送回答字段。因此，发送方在收到确认报文后，可以准确地计算出RTT来。第二、 用于处理TCP序号超过232的情况，这又称为防止序号绕回PAWS。我们知道，TCP报文段的序号只有32位，而每增加232个序号就会重复使用原来用过的序号。当使用高速网络时，在一次TCP连接的数据传送中序号很可能被重复使用。例如，当使用1.5Mbit/s的速度发送报文段时，序号重复要6小时以上。但若用2.5Gbit/s的速率发送报文段，则不到14秒钟序号就会重复。为了使接收方能够把新的报文段和迟到很久的报文段区分开，则可以在报文段中加上这种时间戳。从功能和性能的角度去理解三次握手建立连接第一次：C向S发送一个建立连接的请求。此过程中携带一些报文属性信息，这些信息，存在于报文首部，有初始化用的信息，比如，有用于认证的信息。初始化信息：如报文序列号、SYN：TCP在数据通信之前，通过TCP首部发送的一个SYN标志位，作为建立连接的请求等待接收方确认应答。如果S发来确认应答，则认为可以进行数据通信，否则，就不能进行通信。TCP规定：****SYN=1的报文段不能携带数据，但是要消耗掉一个序号：seq=x。这个时候C进入SYN-SENT(同步已发送)状态。第二次：S收到C请求后，如果同意建立连接，则向C返回确认信息：将SYN、ACK都置1，确认号为ack=seq+1(seq来自客户端)，并携带自己的初始化，同时用于认证的信息S。同理：SYN=1的报文段不能携带数据，但是要消耗掉一个序号：seq=y。这个时候S进入SYN-RCVD(同步已接收)状态。C收到S返回的确认信息后，进入ESTABLISHED(已建立连接)的状态，第三次：C收到S返回的确认信息后，向S再一次发送确认报文。ACK置为1，确认号ack=seq+1(seq来自S),自己的seq=x+1。TCP规定：ACK报文可以携带数据。但是，如果不携带数据，则不消耗序号，这时，下一数据报文段的序号仍是seq=x+1。服务器收到客户端返回的确认信息后，也进入ESTABLISHED(已建立连接)的状态，从功能角度去考虑前两次握手，从性能的角度去理解为什么需要第三次握手。有第三次，是考虑到一种错误情况：假设C发了一请求建立连接的报文，长时间未收到S的确认报文，则C会重发，这个时候S与之建立连接、完成数据通信、关闭了连接，这个时候C第一发出的请求建立连接的报文到达了S,S则会等待C发送数据，实际上C已经CLOSED了，S就一直在这等待，浪费资源，确切地说，应该是至少四次数据交互才能实现一个连接的彻底关闭。关闭连接，需要四个报文来指示关闭。TCP是全双工通信的，所以在一端发送数据完毕后，还具有接收另一端的数据的能力，这就所谓的半关闭。四次挥手举个例子：如果C的数据已经发送完毕，C是不能立即关闭的，因为建立连接的通信双方是平等的。C首先告诉S：“数据发送完毕“，这个消息在TCP报文的首部由FIN来标识，让S知道C是准备断开连接了。这是第一次挥手。S收到C发来的FIN标识的报文后，要给C端恢复一个确认FIN的消息，告诉C说，知道你的数据发完了。这是第二次挥手。这个时候，如果S端的数据也发送完毕了，就给C发一个FIN=1报文。这是第三次挥手。C收到S发来的FIN标识的报文后，要给S端恢复一个确认FIN的消息，告诉C说，知道你的数据发完了。这是第四次挥手。然后就彻底断开连接了。TCP的状态变迁图