tcp三次握手fin(tcp三次握手为什么不是两次)

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。 TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的，可能不可靠的数据报服务。 原则上，TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。互联网络与单个网络有很大的不同，因为互联网络的不同部分可能有截然不同的拓扑结构、带宽、延迟、数据包大小和其他参数。TCP的设计目标是能够动态地适应互联网络的这些特性，而且具备面对各种故障时的健壮性。三次握手过程理解第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。举个例子一对情侣准备周天去看电影。第一次握手 男孩发送：周天去看电影吧。第二次握手 女孩回应：好的。第三次握手 男孩回应：那说好了。1、为什么不能用两次握手进行连接？3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。两次握手出现意外时，将会出现资源的浪费。握手分为Server s，Client c。两次握手，当C想要建立连接时发送一个SYN，然后等待ACK，结果这个SYN因为网络问题没有及时到达S，所以C在一段时间内没收到ACK后，再发送一个SYN，这次S顺利收到，接着C也收到ACK，这时C发送的第一个SYN终于到了S，对于S来说这是一个新连接请求，然后S又为这个连接申请资源，返回ACK，然而这个SYN是个无效的请求，C收到这个SYN的ACK后也并不会理会它，而S却不知道，S会一直为这个连接维持着资源，造成资源的浪费。三次握手出现错误时的应对措施第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受它最后发送的那个SYN的SYN+ACK回应，忽略其他回应全部回应，B中多申请的资源也会释放第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会承认其中它最早发送的那个SYN的回应，并回复最后一次握手的ACK第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST。TCP的四次挥手（1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：标记位为FIN，表示“请求释放连接“；序号为Seq=U；随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文。前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。序号为Seq=W；确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：标记位为ACK，表示“接收到服务器准备好释放连接的信号”。序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。为何要四次分手呢？我们在此之前先说说TCP异常断开的情况TCP异常断开1、如果已经建立了连接，但是一方突然出现故障了怎么办？TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。心跳检测机制在TCP网络通信中，经常会出现客户端和服务器之间的非正常断开，需要实时检测查询链接状态。常用的解决方法就是在程序中加入心跳机制。此外，还有Heart-Beat线程、设置TCP属性等机制。通俗理解断电、死机、这意味着所有状态信息的失,如同-个失忆的人,对外界的一-切是陌生的,即使重新启动、程序征常运行也是如此。另一方肯定还是有正常记忆的,但双方状态(记忆)不对称已经无法完成正常意义的沟通,所以最好的方法,就是让好的一方检测到记忆的不对称,然后把自己的记忆也释放( reset) ,双方再重新谈-场恋爰(TCP重连)。好的一方如何检测呢?TCP Keepalive默认情况下, TCP 120分钟会发送检测信号,如果对方没有回复, 会重试几次到放弃,然后宣布对方翘辫子,发送Reset释放连接。对方收到会莫名其妙,会默默地忽视,因为压根没有这个连接(掉电释放掉了)。2个小时是一个漫长的等待 ,滞留的TCP会话会-直站用资源， 这是一种浪费!Application Keepalive为了更快地检测对方已经Dead的事实,应用程序层面可以发送检测信号,比如5 -10分钟检测一次。通过以上两种常用方法,可以克服好的一方永久驻留在内存里的现状,释放是唯一正确的方法 !实, Application Keepalive除了检测对方是否在线,大的作用是为了避免存在于通信双方之间的NAT设备表超时删除,需要周期性地刷新保活。所以四次挥手也是为了能实时的断开连接，释放资源这也是为了应对意外情况比如客户端在发送一次断开报文后直接自行断开了连接。而这个连接服务器端却没有收到。此时服务器并不知道客户端已经断开了连接。在此期间会一直发送请求判断客户端是否连接。直到最后还没有回应，才会断开连接。TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。举个例子本来一对情侣约好周天去看电影如果是一次挥手即一方发送断开请求之后立即关闭连接。女孩不想去了，就发送：周天不去了，手机就关掉了（关闭连接），如果这个消息没有发送成功。男孩认为约会还是算数的。就一直等待，等待超时的时候询问：还在不在？此时女孩已经关机了，所以接受不到这个信息。男孩可能会等待两个小时之后才选择回去。如果是两次挥手。女孩不想去了，就发送：周天不去了。然后手机没有关机，想确认男孩有没有收到。因为是两次挥手。男孩接到信息后回应：好的。 就选择关机（断开连接，这里先看成男孩已经没有其他数据要发送，因为是两次挥手）。但是回应没有发送到。此时女孩就会一直等，并反复发送消息。但此时男孩已经关机了。女孩可能会反复发送很长时间才选择断开连接。或者男孩回复好的之后，女孩也接受到了，但男孩还有话没说完，想继续聊一聊之前的那个话题，这个话题还很重要。但是因为对面关闭连接也接收不到了。（这就可能出现传输过程中数据的不完整，不满足数据可靠）所以要等双方数据都传输完毕的四次挥手。 可以实时的关闭掉连接。

TCP三次握手 TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:位码即tcp标志位,有6种标示:SYN(synchronous建立联机)ACK(acknowledgement确认)PSH(push传送)FIN(finish结束)RST(reset重置)URG(urgent紧急)Sequencenumber(顺序号码)Acknowledgenumber(确认号码)第一次握手：主机A发送位码为syn=1,随机产生seqnumber=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机;第二次握手：主机B收到请求后要确认联机信息，向A发送acknumber=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包第三次握手：主机A收到后检查acknumber是否正确，即第一次发送的seqnumber+1,以及位码ack是否为1，若正确，主机A会再发送acknumber=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。 完成三次握手，主机A与主机B开始传送数据。

https, 全称Hyper Text Transfer Protocol Secure，相比http，多了一个secure，这一个secure是怎么来的呢？这是由TLS（SSL）提供的，这个又是什么呢？估计你也不想知道。大概就是一个叫openSSL的library提供的。https和http都属于application layer，基于TCP（以及UDP）协议，但是又完全不一样。TCP用的port是80， https用的是443（值得一提的是，google发明了一个新的协议，叫QUIC，并不基于TCP，用的port也是443， 同样是用来给https的。谷歌好牛逼啊。）总体来说，https和http类似，但是比http安全。 http缺省工作在TCP协议80端口(需要国内备案），用户访问网站http://打头的都是标准http服务，http所封装的信息都是明文的，通过抓包工具可以分析其信息内容，如果这些信息内容包含你的银行卡账号、密码，你肯定无法接受这种服务，那有没有可以加密这些敏感信息的服务呢？那就是https！https是http运行在SSL/TLS之上，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。此外客户端可以验证服务器端的身份，如果配置了客户端验证，服务器方也可以验证客户端的身份。https缺省工作在tcp协议443端口，它的工作流程一般如以下方式：1、完成tcp三次同步握手；2、客户端验证服务器数字证书，通过，进入步骤3；3、DH算法协商对称加密算法的密钥、hash算法的密钥；4、SSL安全加密隧道协商完成；5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。附：https一般使用的加密与hash算法如下：非对称加密算法：RSA，DSA/DSS对称加密算法：AES，RC4，3DEShash算法：MD5，SHA1，SHA256如果https是网银服务，以上SSL安全隧道成功建立才会要求用户输入账户信息，账户信息是在安全隧道里传输，所以不会泄密！TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。Web使用HTTP协议作应用层协议，以封装HTTP 文本信息，然后使用TCP/IP做传输层协议将它发到网络上。下面的图表试图显示不同的TCP/IP和其他的协议在最初OSI（Open System Interconnect）模型中的位置：CA证书是什么？CA（Certificate Authority）是负责管理和签发证书的第三方权威机构，是所有行业和公众都信任的、认可的。CA证书，就是CA颁发的证书，可用于验证网站是否可信（针对HTTPS）、验证某文件是否可信（是否被篡改）等，也可以用一个证书来证明另一个证书是真实可信，最顶级的证书称为根证书。除了根证书（自己证明自己是可靠），其它证书都要依靠上一级的证书，来证明自己。https大致过程：1、建立服务器443端口连接 ；2、SSL握手：随机数，证书，密钥，加密算法；3、发送加密请求 ；4、发送加密响应；5、关闭SSL；6、关闭TCP.SSL握手大致过程：1、客户端发送随机数1，支持的加密方法（如RSA公钥加密）；2、服务端发送随机数2，和服务器公钥，并确认加密方法；3、客户端发送用服务器公钥加密的随机数3；4、服务器用私钥解密这个随机数3，用加密方法计算生成对称加密的密钥给客户端；5、接下来的报文都用双方协定好的加密方法和密钥，进行加密.1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流（流模式）;UDP是面向报文的（报文模式），UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信5、TCP要求系统资源较多，UDP较少。TCP首部开销20字节;UDP的首部开销小，只有8个字节SYN：同步序列编号;   ACK=1: 确认序号 ;  FIN附加标记的报文段（FIN表示英文finish）一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，只简单的 描述下这三次对话的简单过程：主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；主机B向主机A发送同意连接和要求同步 （同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：“可以，你什么时候发？”，这是第二次对话；主机A再发出一个数据包确认主机B的要求同 步：“我现在就发，你接着吧！”，这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。为什么需要“三次握手”?在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“ 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误 ”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不一样的表述其实阐明的是同一个问题。谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。 本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。 采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。 主要目的防止server端一直等待，浪费资源。为什么需要“四次挥手”？可能有人会有疑问，在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是 因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。握手，挥手过程中各状态介绍:3次握手过程状态：LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。SYN_SENT : 当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。（发送端）SYN_RCVD : 这个状态与SYN_SENT遥想呼应这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个 ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。（服务器端）ESTABLISHED ：这个容易理解了，表示连接已经建立了。4次挥手过程状态：（可参考下图）：FIN_WAIT_1:这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态， 当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示 半连接 ，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文 ，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）CLOSING（比较少见）:这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。CLOSE_WAIT:这种状态的含义其实是表示在等待关闭。怎么理解呢？ 当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。 所以你在 CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。 （被动方）LAST_ACK:这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）CLOSED:表示连接中断。 TCP的具体状态图可参考：

本文主要内容1、TCP数据包格式TCP数据包格式如下：注意到中间还有几个标志位：数据包格式当中，最重要的是理解序号和确认序号。TCP为什么是稳定可靠的，与序号与确认序号这套机制紧密相关，这也是TCP的精髓。2、TCP的三次握手众所周知，TCP协议是可靠的，而UDP协议是不可靠的。在一些场景中必须用TCP，比如说用户登录，必须给出明确答复是否登录成功等。而有些场景中，用户是否接收到数据则不那么关键，比如网络游戏当中，玩家射出一颗子弹，另外的玩家是否看到，完全取决于当前网络环境，如果网络卡顿，就会有玩家已经被射杀，但界面仍然刷新不出来的情况。这种情形适合UDP。为了保证TCP协议可靠，在建立连接之时就要得到保证。最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED）B服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。3、TCP的传输和确认TCP 传输的可靠性，可以用一句话归结：每收到对方数据，就发送 ACK 进行确定，发送方发送后没有收到 ACK 就隔一段时间重发。就是 A 向 B 发送消息（下面将 TCP 的报文直接看做是消息，消息一词跟 TCP 报文混用），B 收到消息后需要向 A 发送 ACK。这个 ACK 相当于返回结果，没有返回结果，A 就重新发送消息。归纳起来，A 有 3 种消息需要确认。另外 A 也可以发送 RST 消息，代表出错了。出错消息不需要确认。RST 也可以当成返回接口，替代正常的 ACK。返回 ACK，表示消息发送并处理成功，返回 RST 表示消息处理失败。因为通过网络传输，还有第三种结果，就是不确定成功失败。这样归纳起来。就有三种返回结果。这两种具体情况，A 根本识别不了，都只能重发。4、TCP的序号和确认序号A 向 B 发送消息，假如同时发送 a、b、c、d 消息，因为通过网络，这些消息的顺序并非固定的。而 B 返回 ACK 结果，这样就有一个问题，这个结果到底对应了哪个消息？另外当 A 超时重发后，原来的消息延时一段时候，又重新到达了 B，这样 B 就收到两条相同的消息，那么 B 怎么确定这两条消息是相同的呢？为了解决这个对应问题，每一条消息都需要有一个编号，返回结果也应该有一个编号。TCP 的序号可以看成是发送消息的编号，确认序号可以看成是返回结果的编号。有了编号，重复的消息才可以忽略，返回结果(ACK)才可以跟消息对应起来。当建立连接的时候，TCP 选定一个初始序号，之后每发送一个数据包（消息），就将序号递增，保证每发送不同的数据包，数据包的序号都是不同的。TCP 是这样处理的：SYN、FIN 也需要递增序号。不然 A 向 B 重发多个 SYN 或者 FIN, B 根本判断不了 SYN 是否相同，这样就不可以忽略重复的数据包了。当 TCP 发送 ACK 时，相当于返回结果，需要带有确认序号，以便跟发送的消息对应起来。当发送包编号为 a，递增长度为 len。其中 SYN 和 FIN 可以看成是递增长度为 1。这条消息可以这样表示为：现在来回顾三次握手过程。 A 发送序列号x给 B ， B 回复 A 确认号 x+ 1，同时发送序列号 y， A 接收到 B 的回复后，再回复确认号 y+1，同时发送序列号 x+1。给对方的回复一定是接收到的序号加1（或者是数据长度），这样对方才能知道我已经收到了，这样才能保证TCP是可靠的。

TCP协议是在TCP/IP协议模型中的运输层中很重要的一个协议、负责处理主机端口层面之间的数据传输。主要有以下特点：1.TCP是面向链接的协议，在数据传输之前需要通过三次握手建立TCP链接，当数据传递完成之后，需要通过四次挥手进行连接释放。2.每一条TCP通信都是两台主机和主机之间的，是点对点传输的协议。3.TCP提供可靠的、无差错、不丢失、不重复，按序到达的服务。4.TCP的通信双方在连接建立的任何时候都可以发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。5.面向字节流。在数据传输的过程中如果报文比较长的话TCP会进行数据分段传输，每一条分段的TCP传输信息都带有分段的序号，每一段都包含一部分字节流。接收方根据每段携带的的序号信息进行数据拼接，最终拼接出来初始的传输数据。但是在整个传输的过程中每一段TCP携带的都是被切割的字节流数据。所以说TCP是面向字节流的。a.TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用程序一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用程序给出的）。b.如果应用程序传送到TCP缓存的数据块太大，TCP就可以把它划分短一些再传。TCP也可以等待积累有足够多的字节后再构建成报文段发送出去。各字段含义：源端口：发送端的端口号目的端口：接收端的端口号序号：TCP将发送报文分段传输的时候会给每一段加上序号，接收端也可以根据这个序号来判断数据拼接的顺序，主要用来解决网络报乱序的问题确认号：确认号为接收端收到数据之后进行排序确认以及发送下一次期待接收到的序号，数值 = 接收到的发送号 + 1数据偏移：占4比特，表示数据开始的地方离TCP段的起始处有多远。实际上就是TCP段首部的长度。由于首部长度不固定，因此数据偏移字段是必要的。数据偏移以32位为长度单位，因此TCP首部的最大长度是60（15*4）个字节。控制位：URG：此标志表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并且督促 中间层设备要尽快处理这些数据;ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值：0和1， 为1的时候表示应答域有效，反之为0;PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序， 而不是在缓冲区中排队;RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包;SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1， ACK=0;连接被响应的时候，SYN=1，ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送 一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口;但是由于这 种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全 的主机将会强制要求一个连接严格的进行TCP的三次握手;FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志 位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。窗口：TCP里很重要的一个机制，占2字节，表示报文段发送方期望接收的字节数，可接收的序号范围是从接收方的确认号开始到确认号加上窗口大小之间的数据。后面会有实例讲解。校验和：校验和包含了伪首部、TCP首部和数据，校验和是TCP强制要求的，由发送方计算，接收方验证紧急指针：URG标志为1时，紧急指针有效，表示数据需要优先处理。紧急指针指出在TCP段中的紧急数据的最后一个字节的序号，使接收方可以知道紧急数据共有多长。选项：最常用的选项是最大段大小（Maximum Segment Size，MSS），向对方通知本机可以接收的最大TCP段长度。MSS选项只在建立连接的请求中发送。放在以太网帧里看TCP的位置TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。对于应用程序来说，不用关心数据通信的细节。除非线路异常，否则收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。Linux 内核里面 设定 了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。默认情况下，接收方每收到 两个TCP 数据包，就要 发送 一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。ACK 携带两个信息。发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。TCP 协议可以保证数据通信的完整性，这是怎么做到的？前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。如果发送方发现收到 三个 连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。TCP是一个滑动窗口协议，即一个TCP连接的发送端在某个时刻能发多少数据是由滑动窗口控制的，而滑动窗口的大小实际上是由两个窗口共同决定的，一个是接收端的通告窗口，这个窗口值在TCP协议头部信息中有，会随着数据的ACK包发送给发送端，这个值表示的是在接收端的TCP协议缓存中还有多少剩余空间，发送端必须保证发送的数据不超过这个剩余空间以免造成缓冲区溢出，这个窗口是接收端用来进行流量限制的，在传输过程中，通告窗口大小与接收端的进程取出数据的快慢有关。另一个窗口是发送端的拥塞窗口(Congestion window)，由发送端维护这个值，在协议头部信息中没有，滑动窗口的大小就是通告窗口和拥塞窗口的较小值，所以拥塞窗口也看做是发送端用来进行流量控制的窗口。滑动窗口的左边沿向右移动称为窗口合拢，发生在发送的数据被确认时（此时，表明数据已被接收端收到，不会再被需要重传，可以从发送端的发送缓存中清除了），滑动窗口的右边沿向右移动称为窗口张开，发生在接收进程从接收端协议缓存中取出数据时。随着发送端不断收到的被发送数据的ACK包，根据ACK包中的确认序号和通告窗口大小使滑动窗口得以不断的合拢和张开，形成滑动窗口的向前滑动。如果接收进程一直不取数据，则会出现0窗口现象，即滑动窗口左边沿与右边沿重合，此时窗口大小为0，就无法再发送数据。在TCP里，接收端(B)会给发送端(A)报一个窗口的大小，叫Advertised window。1.在没有收到B的确认情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。2.发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。3.发送窗口后沿的后面部分表示已发送且已收到确认。这些数据显然不需要再保留了。4.发送窗口前沿的前面部分表示不允许发送的，应为接收方都没有为这部分数据保留临时存放的缓存空间。5.发送窗口后沿的变化情况有两种：不动（没有收到新的确认）和前移（收到了新的确认）6.发送窗口前沿的变化情况有两种：不断向前移或可能不动（没收到新的确认）TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段。这种重传的概念很简单，但重传时间的选择确是TCP最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到响应的确认的时间这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间。超时重传时间RTO略大于加权平均往返时间RTT：即Round Trip Time，表示从发送端到接收端的一去一回需要的时间，tcp在数据传输过程中会对RTT进行采样（即对发送的数据包及其ACK的时间差进行测量，并根据测量值更新RTT值，具体的算法TCPIP详解里面有），TCP根据得到的RTT值更新RTO值，即Retransmission TimeOut，就是重传间隔，发送端对每个发出的数据包进行计时，如果在RTO时间内没有收到所发出的数据包的对应ACK，则任务数据包丢失，将重传数据。一般RTO值都比采样得到的RTT值要大。如果收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的，选择确认就是一种可行的处理方法。如果要使用选项确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。SACK文档并没有明确发送方应当怎么响应SACK.因此大多数的实现还是重传所有未被确认的数据块。一般说来，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。在计算机网络中的链路容量，交换节点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。拥塞控制方法：1.慢开始和拥塞避免2.快重传和快恢复3.随机早期检测1.一开始，客户端和服务端都处于CLOSED状态2.先是服务端主动监听某个端口，处于LISTEN状态（比如服务端启动，开始监听）。3.客户端主动发起连接SYN，之后处于SYN-SENT状态（第一次握手，发送 SYN = 1 ACK = 0 seq = x ack = 0）。4.服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态（第二次握手，发送 SYN = 1 ACK = 1 seq = y ack = x + 1）。5.客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态（第三次握手，发送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。6.服务端收到客户端的ACK之后，处于ESTABLISHED状态。（需要注意的是，有可能X和Y是相等的，可能都是0，因为他们代表了各自发送报文段的序号。）TCP连接释放四次挥手1.当前A和B都处于ESTAB-LISHED状态。2.A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。3.B收到连接释放报文段后即发出确认，然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP连接处于半关闭状态，即A已经没有数据发送了。从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。4.A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文端。5.若B已经没有向A发送的数据，B发出连接释放信号，这时B进入LAST-ACK(最后确认)状态等待A的确认。6.A再收到B的连接释放消息后，必须对此发出确认，然后进入TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME－WAIT timer）设置的时间2MSL后，A才进入CLOSED状态。7。B收到A发出的确认消息后，进入CLOSED状态。以请求百度为例，看一下三次握手真实数据的TCP连接建立过程我们再来看四次挥手。TCP断开连接时，会有四次挥手过程，标志位是FIN，我们在封包列表中找到对应位置，理论上应该找到4个数据包，但我试了好几次，实际只抓到3个数据包。查了相关资料，说是因为服务器端在给客户端传回的过程中，将两个连续发送的包进行了合并。因此下面会按照合并后的三次挥手解释，若有错误之处请指出。第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段（FIN表示英文finish）。第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序：对方要求关闭连接（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段）。第三步，主机B的应用程序告诉TCP：我要彻底的关闭连接，TCP向主机A送一个FIN报文段。第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。原因有二：一、保证TCP协议的全双工连接能够可靠关闭二、保证这次连接的重复数据段从网络中消失先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。硬件速度网络和服务器的负载请求和响应报文的尺寸客户端和服务器之间的距离TCP 协议的技术复杂性TCP 连接建立握手；TCP 慢启动拥塞控制；数据聚集的 Nagle 算法；用于捎带确认的 TCP 延迟确认算法；TIME_WAIT 时延和端口耗尽。介绍完毕，就这？是的，就这。补充：大部分内容为网络整理，方便自己学习回顾，参考文章：TCP 协议简介TCP协议图文详解什么是TCP协议？wireshark抓包分析——TCP/IP协议TCP协议的三次握手和四次挥手TCP协议详解TCP带宽和时延的研究(1)