TCP协议（传输控制协议）


特点：
     1、面向连接的传输层协议
     2、每一条TCP连接只能有两个端点，及只能是一对一的
     3、TCP提供可靠交付的服务
     4、TCP提供全双工通信
     5、面向字节流
注意：TCP连接的两个端点，不是主机，不是主机的IP地址，不是应用进程，不是传输层的协议端口，而是套接字（socket）。





可靠传输的工作原理
  TCP发送的报文段是交给IP层的，但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输，因此TCP必须采用适当的措施才能使两个传输层之间的通信变得可靠。
  1、停止等待协议（每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组。）




  2、连续ARQ协议和滑动窗口协议



  接收方一般采用累积确认的方式，即接受方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，可以表示到这个分组为止的所有的分组都已经确认收到了。
  优点：容易实现，即使确认丢失也不必重传。
  缺点：不能向发送方反应接受方已经正确收到的所有分组的信息。


TCP报文段的首部格式






数据偏移：即TCP报文段的首部长度。


六个控制位：
     1、紧急URG：为1时，表明紧急指针有效，即告诉系统此报文段中有紧急数据，需要优先传送（相当于高优先级的数据）。
     
     2、确认ACK：仅当ACK为1确认号字段有效。为0时无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1.
     3、推送PSH：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望键入一个命令后立即收到对方的响应。
     4、复位RST：为1时，连接出错，必须释放连接，重新建立连接，此外还用来拒绝一个非法的报文段或拒绝打开一个连接，也称为重建位或重置位。
     5、同步SYN：在连接建立时用来同步序号。
     6、终止FIN：用来释放一个连接。
   
紧急指针：占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的末尾在报文段中的位置。当所有的紧急数据都处理完时，TCP就告诉应用程序恢复到正常的操作。注意，即使窗口为0时也可发送紧急数据。


TCP的连接建立（三次握手）



TCP释放连接（四次挥手）





为什么需要三次握手？
  为了防止已失效的连接请求报文段突然又传送到服务器，因而产生错误。
  例如：client发出的第一个连接请求报文段并没有丢失，而是在某一个网络点滞留了，以致延误到连接释放以后的某一个时间才到达server，本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发送一个新的连接请求。于是就需要做出应答，同意建立连接，假设不采用三次握手，那么只要server发出确认，新的连接就建立了。但server却认为新的运输连接已经建立，并且一直等待client发送数据，这样server的很多资源就会白白的浪费掉了。采用三次握手的办法可以防止上述现象的发生。如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。其主要的目的就是防止server端一直等待，浪费资源。


为什么需要四次挥手？
  这是因为在建立连接时，服务端的LISTEN状态下的SOCKET当收到SYN报文的建立连接请求后，他可以把ACK和SYN放到一个报文里来发送，但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你未必会马上关闭SOCKET，也可能你还有数据需要发送之后，再发送FIN报文给对方来表示你同意关闭连接了，所以他这里的ACK和FIN报文多数情况下都是分开执行的。

TCP协议入门

TCP(Transmission Control Protocol:传输控制协议)
TCP协议是计算机网络中非常复杂的一个协议


TCP协议可靠传输（重要特性）

网络环境复杂
保证数据准确无误到达


TCP协议流量控制

感知对方压力并控制流量


TCP协议拥塞控制

感知网络压力并控制发送速度


TCP报文

面向字节流的协议



应用场景：

微信/QQ等App消息发送接收
浏览器-服务器通信
其他可靠通信的场景

TCP 是互联网核心协议之一，本文介绍它的基础知识。





一、TCP 协议的作用



互联网由一整套协议构成。TCP 只是其中的一层，有着自己的分工。





（图片说明：TCP 是以太网协议和 IP 协议的上层协议，也是应用层协议的下层协议。）



最底层的以太网协议（Ethernet）规定了电子信号如何组成数据包（packet），解决了子网内部的点对点通信。





（图片说明：以太网协议解决了局域网的点对点通信。）



但是，以太网协议不能解决多个局域网如何互通，这由 IP 协议解决。





（图片说明：IP 协议可以连接多个局域网。）



IP 协议定义了一套自己的地址规则，称为 IP 地址。它实现了路由功能，允许某个局域网的 A 主机，向另一个局域网的 B 主机发送消息。





（图片说明：路由器就是基于 IP 协议。局域网之间要靠路由器连接。）



路由的原理很简单。市场上所有的路由器，背后都有很多网口，要接入多根网线。路由器内部有一张路由表，规定了 A 段 IP 地址走出口一，B 段地址走出口二，……通过这套”指路牌”，实现了数据包的转发。





图片说明：本机的路由表注明了不同 IP 目的地的数据包，要发送到哪一个网口（interface）。）



IP 协议只是一个地址协议，并不保证数据包的完整。如果路由器丢包（比如缓存满了，新进来的数据包就会丢失），就需要发现丢了哪一个包，以及如何重新发送这个包。这就要依靠 TCP 协议。



简单说，TCP 协议的作用是，保证数据通信的完整性和可靠性，防止丢包。



二、TCP 数据包的大小



以太网数据包（packet）的大小是固定的，最初是1518字节，后来增加到1522字节。其中， 1500 字节是负载（payload），22字节是头信息（head）。



IP 数据包在以太网数据包的负载里面，它也有自己的头信息，最少需要20字节，所以 IP 数据包的负载最多为1480字节。





（图片说明：IP 数据包在以太网数据包里面，TCP 数据包在 IP 数据包里面。）



TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。



因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。





（图片说明：以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右。）



三、TCP 数据包的编号（SEQ）



一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。



发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。



第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。





（图片说明：当前包的编号是45943，下一个数据包的编号是46183，由此可知，这个包的负载是240字节。）



四、TCP 数据包的组装



收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。



对于应用程序来说，不用关心数据通信的细节。除非线路异常，收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。



TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。



操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。





（图片说明：系统根据 TCP 数据包里面的端口，将组装好的数据转交给相应的应用程序。上图中，21端口是 FTP 服务器，25端口是 SMTP 服务，80端口是 Web 服务器。）



应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。



五、慢启动和 ACK



服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。



最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。



TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。



Linux 内核里面设定了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即”发送窗口”的大小为10。然后停下来，等待接收方的确认，再继续发送。



默认情况下，接收方每收到两个 TCP 数据包，就要发送一个确认消息。”确认”的英语是 acknowledgement，所以这个确认消息就简称 ACK。



ACK 携带两个信息。

期待要收到下一个数据包的编号

接收方的接收窗口的剩余容量



发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为”发送窗口”，这个窗口的大小是可变的。





（图片说明：每个 ACK 都带有下一个数据包的编号，以及接收窗口的剩余容量。双方都会发送 ACK。）



注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。





图片说明：上图一共4次通信。第一次通信，A 主机发给B 主机的数据包编号是1，长度是100字节，因此第二次通信 B 主机的 ACK 编号是 1 + 100 = 101，第三次通信 A 主机的数据包编号也是 101。同理，第二次通信 B 主机发给 A 主机的数据包编号是1，长度是200字节，因此第三次通信 A 主机的 ACK 是201，第四次通信 B 主机的数据包编号也是201。）



即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。



六、数据包的遗失处理



TCP 协议可以保证数据通信的完整性，这是怎么做到的？



前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。



举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。



如果发送方发现收到三个连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。



（图片说明：Host B 没有收到100号数据包，会连续发出相同的 ACK，触发 Host A 重发100号数据包。）

人工智能，零基础入门！http://www.captainbed.net/inner


TCP三次握手和四次挥手的问题在面试中是最为常见的考点之一。很多读者都知道三次和四次，但是如果问深入一点，他们往往都无法作出准确回答。

本篇尝试使用动画来对这个知识点进行讲解，期望读者们可以更加简单地地理解TCP交互的本质。

一、TCP 三次握手

TCP 三次握手就好比两个人在街上隔着50米看见了对方，但是因为雾霾等原因不能100%确认，所以要通过招手的方式相互确定对方是否认识自己。



张三首先向李四招手(syn)，李四看到张三向自己招手后，向对方点了点头挤出了一个微笑(ack)。张三看到李四微笑后确认了李四成功辨认出了自己(进入estalished状态)。

但是李四还有点狐疑，向四周看了一看，有没有可能张三是在看别人呢，他也需要确认一下。所以李四也向张三招了招手(syn)，张三看到李四向自己招手后知道对方是在寻求自己的确认，于是也点了点头挤出了微笑(ack)，李四看到对方的微笑后确认了张三就是在向自己打招呼(进入established状态)。

于是两人加快步伐，走到了一起，相互拥抱。



我们看到这个过程中一共是四个动作，张三招手--李四点头微笑--李四招手--张三点头微笑。其中李四连续进行了2个动作，先是点头微笑(回复对方)，然后再次招手(寻求确认)，实际上可以将这两个动作合一，招手的同时点头和微笑(syn+ack)。于是四个动作就简化成了三个动作，张三招手--李四点头微笑并招手--张三点头微笑。这就是三次握手的本质，中间的一次动作是两个动作的合并。

我们看到有两个中间状态，syn_sent和syn_rcvd，这两个状态叫着「半打开」状态，就是向对方招手了，但是还没来得及看到对方的点头微笑。syn_sent是主动打开方的「半打开」状态，syn_rcvd是被动打开方的「半打开」状态。客户端是主动打开方，服务器是被动打开方。

【1】syn_sent: syn package has been sent

【2】syn_rcvd: syn package has been received

二、TCP 数据传输

TCP 数据传输就是两个人隔空对话，差了一点距离，所以需要对方反复确认听见了自己的话。



张三喊了一句话(data)，李四听见了之后要向张三回复自己听见了(ack)。

如果张三喊了一句，半天没听到李四回复，张三就认为自己的话被大风吹走了，李四没听见，所以需要重新喊话，这就是tcp重传。

也有可能是李四听到了张三的话，但是李四向张三的回复被大风吹走了，以至于张三没听见李四的回复。张三并不能判断究竟是自己的话被大风吹走了还是李四的回复被大风吹走了，张三也不用管，重传一下就是。

既然会重传，李四就有可能同一句话听见了两次，这就是「去重」。「重传」和「去重」工作操作系统的网络内核模块都已经帮我们处理好了，用户层是不用关心的。



张三可以向李四喊话，同样李四也可以向张三喊话，因为tcp链接是「双工的」，双方都可以主动发起数据传输。不过无论是哪方喊话，都需要收到对方的确认才能认为对方收到了自己的喊话。

张三可能是个高射炮，一说连说了八句话，这时候李四可以不用一句一句回复，而是连续听了这八句话之后，一起向对方回复说前面你说的八句话我都听见了，这就是批量ack。但是张三也不能一次性说了太多话，李四的脑子短时间可能无法消化太多，两人之间需要有协商好的合适的发送和接受速率，这个就是「TCP窗口大小」。

网络环境的数据交互同人类之间的对话还要复杂一些，它存在数据包乱序的现象。同一个来源发出来的不同数据包在「网际路由」上可能会走过不同的路径，最终达到同一个地方时，顺序就不一样了。操作系统的网络内核模块会负责对数据包进行排序，到用户层时顺序就已经完全一致了。

三、TCP 四次挥手

TCP断开链接的过程和建立链接的过程比较类似，只不过中间的两部并不总是会合成一步走，所以它分成了4个动作，张三挥手(fin)——李四伤感地微笑(ack)——李四挥手(fin)——张三伤感地微笑(ack)。



之所以中间的两个动作没有合并，是因为tcp存在「半关闭」状态，也就是单向关闭。张三已经挥了手，可是人还没有走，只是不再说话，但是耳朵还是可以继续听，李四呢继续喊话。等待李四累了，也不再说话了，超张三挥了挥手，张三伤感地微笑了一下，才彻底结束了。



上面有一个非常特殊的状态time_wait，它是主动关闭的一方在回复完对方的挥手后进入的一个长期状态，这个状态标准的持续时间是4分钟，4分钟后才会进入到closed状态，释放套接字资源。不过在具体实现上这个时间是可以调整的。

它就好比主动分手方要承担的责任，是你提出的要分手，你得付出代价。这个后果就是持续4分钟的time_wait状态，不能释放套接字资源(端口)，就好比守寡期，这段时间内套接字资源(端口)不得回收利用。

它的作用是重传最后一个ack报文，确保对方可以收到。因为如果对方没有收到ack的话，会重传fin报文，处于time_wait状态的套接字会立即向对方重发ack报文。

同时在这段时间内，该链接在对话期间于网际路由上产生的残留报文(因为路径过于崎岖，数据报文走的时间太长，重传的报文都收到了，原始报文还在路上)传过来时，都会被立即丢弃掉。4分钟的时间足以使得这些残留报文彻底消逝。不然当新的端口被重复利用时，这些残留报文可能会干扰新的链接。

4分钟就是2个MSL，每个MSL是2分钟。MSL就是maximium segment lifetime——最长报文寿命。这个时间是由官方RFC协议规定的。至于为什么是2个MSL而不是1个MSL，我还没有看到一个非常满意的解释。

四次挥手也并不总是四次挥手，中间的两个动作有时候是可以合并一起进行的，这个时候就成了三次挥手，主动关闭方就会从fin_wait_1状态直接进入到time_wait状态，跳过了fin_wait_2状态。

四、总结

TCP状态转换是一个非常复杂的过程，本文仅对一些简单的基础知识点进行了类比讲解。关于TCP的更多知识还需要读者去搜寻相关技术文章进入深入学习。如果读者对TCP的基础知识掌握得比较牢固，高级的知识理解起来就不会太过于吃力。