关于tcp:TCP学习笔记二-相识篇

前言

很久之后，你开始学习计算机网络，不是为了面试，只是为了解决工作中遇到的问题，在遇到工作中遇到网络问题之前，你的想法是工作中作为一个 CRUD 仔，网络是通顺的，不要放心网络问题，然而这次碰到的网络问题很让你头疼，为了解决这个问题你用尽了浑身解数，最终问题被解决，这次问题解决之后，你打算彻底学习一下计算机网络。聊一下三次握手吧，我在实习筹备面试题的时候，三次握手和四次握手就是高频面试题，我选择性的放弃了这个经典的面试题，因为大学的时候学的计算机网络并不好，其实刚开始我还是蛮有趣味的，然而前面发现越听越听不懂，索性就开始刷知乎，看数学书，过后听不懂这门课的起因，我想一大部分起因在于过后没有多少代码量，程序是认知计算机世界的桥梁，而后老师显然没有意识到这一点，当然学校也没意识到，其实还有其余课程，也面临这样的问题。然而有的时候工作中会碰到，所以只好花工夫重修，然而也不悔恨大学将工夫奉献给了数学，我很思念那段时光，忽然懂得某一个数学定理，我过后记得花了一个月还是多久才解出了低等代数的一道课后习题，过后开心了很久。

咱们来回顾一下《TCP 学习笔记(二) 初遇篇》的内容:

TCP 是面向连贯的运输层协定，这就是说应用程序在应用 TCP 协定之前，必须先建设 TCP 连贯，在数据开释完之后，必须开释曾经建设的 TCP 连贯。

TCP 提供牢靠交付的服务。通过 TCP 连贯传送的数据。无差错、不失落、不反复，并且按序达到。

为了确保不失落，在报文在网络环境中失落之后，TCP 建设了重传机制，在网络拥挤的状况，报文失落的频率比拟高，在这种状况下，进行重传会进一步加深网络拥挤的水平，所以 TCP 引入了拥塞管制。

TCP 提供全双工通信。TCP 容许通信单方的利用过程在任何时候都可能发送数据

TCP 是面向连贯的协定，连贯能够了解为通信单方之间的一条路线，通过连贯进行运输报文。在 TCP 中传送报文分为三个阶段:

• 连贯建设
• 数据传送
• 连贯开释

TCP 连贯的建设次要是为了解决以下三个问题:

• 要使得通信的单方可能确知对方的存在
• 要容许单方协商一些参数
• 可能对运输实体资源 (缓存大小、连贯表中的我的项目) 进行调配。

TCP 连贯的建设采取客户和服务器模式。被动发动连贯建设的利用过程称之为客户，而被动期待连贯建设的利用过程叫做服务端。我在写 TCP 的时候想找两个客户端的通信的代码示例，因为 Java 外面应用 TCP 协定大抵上有 ServerSocket 和 Socket 这两个类，ServerSocket 是服务端，Socket 是客户端。看到这里才发现人家 TCP 自身就是客户和服务器模式。

咱们本篇次要讲连贯建设和连贯开释，也就是为宽广程序员耳熟能详的三次握手和四次握手。

连贯建设 - 三报文握手

其实是三报文握手，不是三次握手，其实是一次握手中替换了三个报文，而并不是握了三次手，参见 RFC 793(谢希仁的那本教材说是 RFC 973，我在百度上找了好久没找到，搜寻 RFC 793 就找到了，想来是不是作者手滑打错了)。在 RFC 793 三次握手对应的形容如下:

The procedures to establish connections utilize the synchronize (SYN) control flag and involves an exchange of three messages. This exchange has been termed a three-way hand shake [3]

程序在建设连贯应用 SYN 管制标记并进行三次音讯替换，这种替换也被称之为三报文握手。

教材中认为叫应该三报文握手的起因在于，三次握手从字面上推断为握手握了三次，其实是一次握手替换了三个报文，像是初次见面握手高低摇摆了三次。

我批准这个观点，晚期我看到三次握手就认为是握了三次手，咱们先大抵介绍三报文的握手来领会为什么，客户端和服务端替换三个报文之后就可能确知对方的存在和协商后续的报文传输的相干问题。

TCP 建设连贯的过程叫做握手，握手须要在客户和服务器之间替换是三个 TCP 报文段，为了探讨问题，咱们当初首先要引入两台通信的计算机 A 和 B，A 和 B 的通信过程应用 TCP 协定，A 为客户端，B 为服务端。一开始 B 的服务器过程首先创立运输管制块 TCB(Transmission Control Block), 而后服务器过程就开始解决 Listen 状态，期待客户端的连贯申请。写到这里 Java 程序员有没有想到 Java 中的 Socket 编程，在 BIO 中也是先 new ServerSocket, 而后监听某个端口，而后调用 accept 办法侦听客户端过程，该办法会阻塞到直到有客户端申请进来，会返回一个 Socket 对象：

    public void serverSocketDemo() throws Exception{
        // 申明该 Socket 占用的过程
        ServerSocket serverSocket = new ServerSocket(8080);
        // 监听哪个端口
        serverSocket.bind(new InetSocketAddress(9090));
        // 开始监听, 有客户端申请进来, 会返回给一个 Socket 对象
        // Socket 中有输入输出流
        // 能够用来读写数据
        Socket socket = serverSocket.accept();
        InputStream inputStream = socket.getInputStream();
        OutputStream outPutStream = socket.getOutputStream();}

基本上高级语言 Socket 编程都是这个步骤，先创立 ServerSocket，而后占用端口，只不过侦听办法有的叫 accept，有的叫 listen，其实都是一样的原理。

A 的 TCP 过程也是首先创立传输管制模块 TCP。而后，在打算建设 TCP 连贯时，向 B 收回连贯申请报文段，这是首部中的同部位 SYN=1，同时抉择一个初始序号 seq = x。TCP 规定，SYN 报文段 (即 SYN = 1 的报文段) 不能携带任何数据，但要耗费一个序号。这时 TCP 客户过程进入 SYN-SENT(同步已发送状态)。

B 收到连贯申请报文段后，如批准建设连贯，则向 A 发送确认。在确认报文段中应该把 SYN 位和 ACK 地位都置 1，确认好是 ack = x + 1，同时也会为本人抉择一个初始序号 seq=y。请留神，这个报文段也不能携带数据，但同样要消耗掉一个序号。这是 TCP 服务器过程进入 SYN-RCVD(同步收到)状态。

TCP 客户端过程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置为 1，确认号 ack = y +1，而本人的序号 seq = x + 1。TCP 标准规定，ACK 的报文段能够携带数据。但如果不携带数据则不耗费序号，在这种状况下，下一个数据报文段的序号依然是 seq = x + 1。这时，TCP 连贯曾经建设，A 进入 ESTABLISHED 状态。

下面给出的连贯建设过程咱们称之为三报文握手，建设过程如下图所示:

那么对于这个过程来说，第一个问题就是客户端在收到服务端的确认报文之后，为什么还要在向服务端发送一个确认报文，这个答案在 RFC-793 中答复了这个问题:

The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.

三报文握手的起因是为了避免旧的反复连贯初始化造成凌乱。

咱们上面来通过一个场景来解释下面这句话，假如 A 发送的第一个申请报文在某些网络结点中滞留了很久，A 认为此报文曾经遗失，于是又再次发送了一个申请建设连贯的报文，如果在这种状况下旧的报文比新的早达到 B，如果只有两次握手，那么 B 就会认为和 A 建设了两个连贯，然而旧的连贯中，A 并不会再向 B 发送数据，这样服务端 B 的资源就白白被节约了。如果是三报文握手，B 收到了旧的报文之后，返回 A 一个 SYN+ACK 报文给客户端。客户端收到后就能够依据本身的上下文，判断这是一个历史连贯(序列号过期或超时)，那么客户端就会发送申请停止连贯报文给服务端，示意停止这一次的连贯，能够防止服务端的资源被节约。

再有在网络拥挤的状况下，如果只是两报文交换就建设了 TCP 连贯，在网络拥挤下，客户端会发送很多申请建设连贯的报文，服务端收到一个申请连贯建设的报文，就建设一个连贯会造成大量服务端资源的节约。

TCP 提供牢靠传输，发送发送的音讯也须要按序进行交付，在建设连贯的开始，客户端的报文中有一个序列号的字段，由单方独特保护，序列号是牢靠传输的一个关键因素，它的作用为:

• 接管方能够去除反复的数据。
• 接管方能够依据数据包的序列号按序接管
• 能够标识发送进来的数据包中，哪些是被对方收到的。

其实 B 给 A 发送的确认报文也能够被拆成两次发送，能够先发送一个确认报文端(ACK = 1, ack = x +1), 而后再发送一个同步报文端(SYN = 1,seq = y), 这样的过程就变成了四报文握手，也能实现一样的成果，然而支流的实现是将这两步合成一步。

连贯开释 - 四报文挥手

其实依照我最后的想法是，连贯建设须要经验三次报文握手是比拟正当的，然而开释连贯要经验四报文挥手我就有点不了解了，间接一次性挂掉不行吗？你能够联想到生存中这样的一个场景就是，俩人打电话，有一方话还没谈话，另一方就挂了，通常过早挂电话还会再给另一方打一次电话。咱们还是先介绍连贯开释的过程，再去提出问题。

首先还是下面两个曾经建设连贯的两台计算机，或者说是两个计算机过程，而后此时 A 须要敞开连贯了, A 的利用过程首先向其 TCP 收回连贯开释报文段，并进行发送数据，被动敞开 TCP 连贯。A 把连贯开释报文段首部的终止位 FIN 置 1，其序号 seq = u，它等于后面已传送的数据的最初一个字节的序号加 1. 这时 A 进入 FIN-WAIT-1(终止期待 1)状态，期待 B 的确认。请留神，TCP 规定 FIN 报文段即便不携带数据，它也会消耗掉一个序号。

B 收到连贯开释申请后收回确认，确认好是 ack = u + 1，而这个报文段本人的序号是 v，等于 B 后面曾经传送的数据的最初一个字节的序号 +1. 而后 B 就进入 CLOSE-WAIT 状态(期待敞开状态)，但此时的 TCP 连贯初遇半敞开状态，即 A 曾经没有数据要发送了，但 B 如果要发送数据的话，A 依然要接管，这也就是 B 到 A 这个方向的连贯并未敞开，还是可能继续一段时间。

A 收到 B 的确认之后，就进入到了 FIN-WAIT-2(终止期待 2)状态，期待 B 收回的连贯开释报文段。若 B 曾经没有要向 A 发送的数据了，其利用过程就通过操作系统对外裸露的 TCP 接口申请操作系统开释连贯。这时，B 收回的连贯开释报文段必须使 FIN = 1. 现假设 B 的序号为 w(在半敞开状态 B 可能又发送了一些数据)。B 还必须反复上次已发送过的确认好 ack = u + 1. 这时 B 就进入 LAST-ACK(最初确认)状态，期待 A 的确认。

A 在收到 B 的连贯开释报文段后，必须对此收回确认。在确认报文段中把 ACK 置为 1、确认号 ack = w + 1，而本人的序号是 seq = u + 1(依据 TCP 规范, 后面发送给的 FIN 报文段要耗费一个序号)。而后进入到 TIME-WAIT(工夫期待)的状态。请留神，当初 TCP 连贯还没有开释掉。必须通过工夫期待计时器(TIME-WAIT timer) 设置的工夫 2MSL 后，A 才进入到 CLOSED 状态。工夫 MSL 叫做最长报文段寿命(Maxumum Segment Lifetime)，RFC-793(当初看来教材的确写错了，这里写的是 RFC-793，刚开始介绍 TCP 实践的是 RFC-973)，RFC-793 倡议设置为两分钟。这齐全是从工程上思考的，对于当初的网络来说，MSL = 2 分钟可能太长了一些。因而 TCP 容许不同的实现可依据具体情况应用更小的 MSL 值。因而 A 进入到 TIME-WAIT 状态，要通过 4 分钟能力进入到 CLOSED 状态，当 A 撤销相应的传输管制块 TCB 后，就完结了这次的 TCP 连贯。

咱们提出的第一个问题就是为什么回收须要四次? 其实下面的挥手过程曾经给出答案了:

• 敞开连贯时，客户端向服务端发送 FIN 时，仅仅示意客户端不再发送数据了，然而还能接收数据。
• 服务器接管到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据须要解决和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来示意对立当初敞开连贯。

从下面过程可知，服务端通常须要期待实现数据的发送和解决，所以服务端的 ACK 和 FIN 个别都会离开发送，从而比三次握手导致多了一次。咱们画个图来描述一下四次挥手的过程:

从下面的过程可知，服务端通常须要期待实现数据的发送和解决，所以服务端的 ACK 和 FIN 个别都会离开发送，从而比三次握手导致多了三次。

下一个问题是为什么 A 发送完最初一个连贯开释报文之后，还须要期待 2MSL。

• 为了保障 A 发送的最初一个 ACK 报文段可能达到 B。这个 ACK 报文有可能失落，因此使处在 LAST—ACK 状态的 B 收不到已发送到确认，而 A 可能在这段时间重传一次确认，重新启动 2MSL 计时器。最初，A 和 B 都可能失常进入敞开状态。
• 避免旧连贯的数据包被收到。假如客户端没有 TIME-WAIT 工夫或者等待时间过短，有提早的数据包达到会产生什么呢？

如果此时雷同的端口的 TCP 连贯被复用之后, 那么就有可能失常接管这个过期的报文，那么就会产生数据错乱等重大问题。期待的这段时间，通过 2MSL 这个工夫足够让两个方向上的数据包被抛弃，使得原来连贯的数据包在网络中天然隐没，再呈现的数据包肯定是新连贯所建设的。

TIME_WAIT 期待 2 倍的 MSL，比拟正当的解释是: 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接管方解决后又会向对方发送响应，所以这一来一回须要期待 2 倍的工夫。

举一个例子如果被动敞开方没有收到断开连接的最初的 ACK 报文，就会触发超时重发 Fin 报文，另一方接管到 FIN 后，会重发 ACK 给被动敞开方，这一来一回刚好 2 个 MSL。

其实看到这里的疑难是 TCP 是如何保障最长报文段寿命，我认为 TCP 的报文中会有这样一个字段来阐明本人的寿命，查阅诸多材料发现，没有找到对应的材料阐明。StackOverFlow 中也有人跟我有一样的疑难，搜寻: What is Maximum Segment Lifetime(MSL) IN TCP 相干问题就能看到答主跟我有一样的疑难.

那如果客户端无端重启，那服务端的连贯会敞开不了吗？当然不会 TCP 还有一个保活计时器。服务器没收到一次客户的数据，就从新设置保活计时器，工夫的设置是通常是两小时。若两小时没收到客户的数据，服务器就发送一个探测报文段，当前每隔 75 秒钟发送一次。若一连发送 10 个探测报文段仍无客户的响应，服务器就认为客户端出了故障，接着就敞开这个连贯。

处于 time-wait 的 TCP 连贯不能被重用，个别有人看到这里可能有人会问，我用多线程应用 HTTP Client 多线程调用，两个距离十分短的状况下，也实现重用了呀。那是因为在操作系统中提供了重用端口这个选项，即便该端口还被上一个连贯所占用还没开释，咱们仍然能够通过重用地址发动新的连贯：

   public void serverSocketDemo() throws Exception{Socket socket = new Socket();
        // 容许处于 time-wait 中的端口，发动新的连贯。socket.setReuseAddress(true);
    }

总结一下

咱们常常谈起的三次握手, 更为贴切的称说是三报文握手, 应用 SYN 相干的报文，客户端和服务端替换三次。为什么客户端收到服务端的确认之后，还须要再发送一次确认。起因在于避免旧的连贯造成连贯凌乱和资源节约，如果 A 发送的申请建设连贯报文，此报文在网络中滞留了很长时间，超过了超工夫，A 再次发了一个申请建设连贯的报文，如果只有两次握手，那么滞留的报文也将建设连贯，白白造成资源节约。

那为啥敞开连贯要四次，因为客户端发送数据发送结束之后，服务端还可能有数据没解决和发送完，所以多了一次握手。那为什么收到服务端发送的连贯敞开报文，客户端不立刻敞开连贯，而是进入 TIMEWAIT 状态，有两个起因，第一个保障连贯正确的被敞开，因为 A 发送的确认 ACK 报文可能在网络中滞留和失落，如果 A 在发送确认报文 ACK 之后立刻敞开，假如失落之后，服务端就可能无奈正确敞开连贯。第二个就是避免旧的的数据包被新的连贯收到，思考以下两种状况:

• 如果网络极差，B 始终未收到 A 发送的 ACK，B 会一直重传直到达到操作系统的重传工夫或次数，而后敞开连贯；如果 A 如果始终未收到 B 重传的 FIN，会再期待 2 个 MSL 后开释资源。最终 A，B 也实现了连贯的断开，资源的开释。
• TIME_WAIT 状态期待 2MSL，思考的是 B 总是能收到 A 的 ACK，但因为拥塞，可能收到的比较慢，最慢为 1 个 MSL，如果通过 1MSL, B 还是没收到，就永远收不到 ACK 了，此时进化为第一种状况。此时间隔 A 发送 ACK 过了 1MSL，B 曾经可能多次重传了 FIN，并且因为收到 ACK，之后不会再重传 FIN。此时 A 如果收到过新的 FIN，就曾经开始了从新计时，从新期待 2 个 MSL；A 如果始终没收到新的 FIN，就再期待 1 个 MSL，让 B 之前重传的报文在网络中消失。

参考资料

• RFC 793 TCP 的规范文档 https://www.rfc-editor.org/rf…
• 《计算机网络 (第 7 版)》谢希仁著 电子工业出版社
• 对于三次握手和四次挥手，面试官想听到怎么的答复？https://www.zhihu.com/questio…
• Time-wait 状态 (2MSL) 一些了解 https://blog.csdn.net/oversta…