计算机网络 tcp相关知识

计算机网络常见问题

传输层协议

q1 tcp的握手过程

       tcp网络的握手过程分为3次，正如大多数博客所讲的基础过程也就是浏览器（client）发送请求到服务器（server），然后server返回client，然后在client在返回server。如下图

       但面对这么过程中有许多的细节，例如为什么是3次，选择序列号有什么讲究等问题。
       首先来tcp是一个稳定的传输协议，它的稳定性依赖于arq协议，那么对于后面的过程来说，确定端对端能否交流就是一个重要的过程，3次握手协议意义在此。
       通俗来说：3次握手就是2个位置的端设备在试探的过程，以下发送用send，接受有recv表示。所以我们分别从client和server的角度去分析这个过程详细过程（client发送的第一次消息，这个过程中，client对自己的send与recv功能都是一无所知的，如果这个时候server接收到了消息，那么这个时候server已经知道自己的recv功能ok，client的send功能ok，但他不知道自己的send以及client的recv是不是ok，这个时候client还是一无所知。第二次握手过程是server给client发消息，这个时候client收到了消息，client明白了自己的recv与send其实都ok，同时他也知道server的recv与send都ok。而第三次握手则是为了让server了解，自己的send其实是ok的。这样三次握手，就达到了双方互相知道的效果。）
       当然如果你想表达更加专业点:tcp的3次连接是一个双工过程。这个术语我最先从操作系统的通信机制中了解到的，父进程与子进程通过匿名管道进行半双工过程通信。而这种情况下，他们只需要一端能用即可。而在tcp的过程中需要read和write都能用，所以3次握手是最快能确认tcp能够进行双工通信的方式。

q2 tcp的挥手过程

tcp的4次挥手过程如下图

       无论理解挥手还是握手问题，最主要的是分析端与端之间的双工过程，4次挥手与握手相反，他是一个关闭过程。

1. 在第一次挥手过程中client会选择请求关闭连接.
2. server收到后，必须马上回复消息给client，以便让他知道此次的请求没有丢失。
3. client收到后，就知道请求以及送达不会重发。
4. server完成最后的数据传输。
5. client受到请求关闭。

       4次握手中多出的那次握手其实也很好理解，我必须保证包不能超时 ，处于职业信仰马上给你回到ack，我收到了你消息了。但我server端手里还有活没干完，所以继续处理然后返回请求断开。最后由客户端完成ack。

q3 字段与状态

       众所周知，tcp的头部有6个标志位，常见的有syn与fin。分别是用于开始与结束的。syn的上面部分可以知道，出现过2次。而syn字段的特殊性，使得使用一个内存缓冲区去储存该请求，所谓的syn攻击，也就是利用这一特性，使得大量的半连接syn请求打入服务器，导致缓冲区溢出，程序崩溃的效果。
       而四次挥手过程中考察最多的状态是time_wait状态。这个状态的设置需要抓住2个要点，第一点是：作为最后结束的严谨性。第二点：存活周期为2msl。
       其实第一点很好理解，其实有没有想过为啥最后一次ack后server不需要继续ack返回client告诉自己收到了，这样会无限套娃。server告诉client收到ack的最好的方式就是不说话，因为没收到ack肯定会超时重新发送fin请求。所以这里需要等待是一种严谨性，确保超时前自己的消息确实被server知道了。
       第二点理解需要结合一定的知识。有一些包会在链路中游离，client发送一个包，它认为他已经超时了，就在发送那个包，但是他并没有丢，只是晚到了。2个MSL是确认此次过程中的任何一个包都会消失，要不然，如果在重新连接上之前的过程。那么在任何一个过程中如果收到了之前的包，会导致2端发生意想不到的错误。

以下状态码说明来自维基百科
LISTEN S
       服务器等待从任意远程TCP端口的连接请求。侦听状态。
SYN-SENT C
       客户在发送连接请求后等待匹配的连接请求。通过connect()函数向服务器发出一个同步（SYNC）信号后进入此状态。
SYN-RECEIVED S
       服务器已经收到并发送同步（SYNC）信号之后等待确认（ACK）请求。
ESTABLISHED S&C
       服务器与客户的连接已经打开，收到的数据可以发送给用户。数据传输步骤的正常情况。此时连接两端是平等的。这称作全连接。
FIN-WAIT-1 S&C
       （服务器或客户）主动关闭端调用close（）函数发出FIN请求包，表示本方的数据发送全部结束，等待TCP连接另一端的ACK确认包或FIN&ACK请求包。
FIN-WAIT-2 S&C
       主动关闭端在FIN-WAIT-1状态下收到ACK确认包，进入等待远程TCP的连接终止请求的半关闭状态。这时可以接收数据，但不再发送数据。
CLOSE-WAIT S&C
       被动关闭端接到FIN后，就发出ACK以回应FIN请求，并进入等待本地用户的连接终止请求的半关闭状态。这时可以发送数据，但不再接收数据。
CLOSING S&C
       在发出FIN后，又收到对方发来的FIN后，进入等待对方对己方的连接终止（FIN）的确认（ACK）的状态。少见。
LAST-ACK S&C
       被动关闭端全部数据发送完成之后，向主动关闭端发送FIN，进入等待确认包的状态。
TIME-WAIT S/C
       主动关闭端接收到FIN后，就发送ACK包，等待足够时间以确保被动关闭端收到了终止请求的确认包。【按照RFC 793，一个连接可以在TIME-WAIT保证最大四分钟，即最大分段寿命（maximum segment lifetime）的2倍】
CLOSED S&C
       完全没有连接。

q4 tcp传输相关

tcp的传输有很多面试的题目，这些题目都是考察你对tcp传输的过程理解。

tcp的传输最为重要与被人问起的性质是可靠性，tcp为了可靠性设置了很多规则维护他。它的往来就是想是很笨的人说话一样，每一次消息都需要进行ACK确认。那当人问起你如何保证tcp的可靠性的时候，你回答用ack确认其实不完全，这个时候对面就问你，一个ack就能达到可靠性传输吗？其实tcp的可靠性主要体现在确认机制以及超时重传机制，而对应的这个过程就是arq协议。

你或许之前没听过这个协议，自动重传请求（Automatic Repeat-reQuest，ARQ）。这个协议与传输过程仅仅相关。此协议通过确认与超时机制，在不可靠的服务基础上面实现可靠性传输。

ARQ协议包括停止等待ARQ协议和连续ARQ协议，错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和 负面确认及重传（Negative Acknowledgment and Retransmission）等机制。

而我们可以从实际情形入手，由于tcp的传输长度是有限制的，我们如果只是发一些消息，它很容易放在一个包内，但是如果需要发一张图片的话，它可能会由于大小不得不将一张图片进行切分处理。每一块图片都是一个包，在tcp中处理数据有2种形式3种方式。

1. 单包发送
   此种形式下发送与接受都是一个包一个包的确认，这种情况下，信道利用率高，其实作为设计者的角度出发，它可以看做成send与recv大小都为1的滑动窗口。对应与ARQ协议就是停止等待ARQ协议。

2. 连续包发送

   • 回退N帧协议：对应的是连续ARQ协议，其实与下面的开始过程类似，根据窗口大小协商好一个信息，然后发送一些列的包，如果出现超时现象，那么会很悲观的认为，哪一个超时包之后的所有包都丢失了，而且接收者也会放弃超时之后的所有包。所以将超时后所有的包再发一遍。
   • 选择重传协议：此协议会设置一个缓冲区用来接受所有到达的消息，如果一个消息到达了在窗口内，他就会将消息返回ACK，并进入缓冲区，按照顺序给上层协议。

这里滑动窗口的大小是由发送发与接收方所共同决定的，这里接下来会提到tcp的重要优化链路算法，流量控制与拥塞避免。

要想理解上面的算法，必须从设计的出发点考虑，在网络传输过程中会出现很多的问题，如果你想要连续的发送一些数据，不得不从端对端与链路2方面进行考虑，为了维护与控制整个链路，需要对不必要的流量进行控制，对拥塞的情况进行维护。

• 流量控制：简单来说，如果接收方无法接受过大的流量，比如我带宽没办法跟得上你发送方的输出，这种情况下，由于我接收方接受速度很慢，会导致已经到达包到了一些端设备，但是他并不是丢失了，仅仅因为我接受速度不够而导致没能及时读取，这样会让发送方误认已丢失再次重发，这样会造成不必要的流量损失。这里再提一个窗口叫rwnd。

• 拥塞避免：拥塞避免分为3个具体的算法，慢启动、快速重传、快速恢复，一个窗口cwnd（congestion window）。

  • 慢启动是一个不断在调整的过程，可以在最开始的时候设置很小的cwnd，比如1个MSS。然后第一次发送完后，就给他加倍，然后超级加倍哈哈哈。你在增长到20次那就是百万级别了。所以肯定不不能没有限制的增长，这里会设置一个ssthresh（慢启动阈值）。每当TCP出现了丢包时间（认定为拥塞发生）TCP发送方会把cwnd重置为1个MSS长度。然后这个时候的ssthresh设置称为发送丢包时候的一般长度，即cwnd/2。其实我们假设下一次发生拥塞的时候在和第一次一样，那么很显然如果到了这个阈值继续慢启动，只能在狗一次，还是gg。这个时候他就会改变上升的方式。结束当前的慢启动，转化到拥塞避免模式。其实还有一种结束慢启动的方式，那就是受到了3个冗余的ACK这个时候TCP会执行一种快速重传，并进入快速恢复。
  • 快速重传：收到高于需要确认号的时候，接收方这个时候有理由认为那个包出问题了，这里需要了解一个知识，比如我现在序列号是1101，而我的包大小为100，我发了过去，那么对方请求我的下一个包应该为1201.所以当收到乱序包，他会立刻把这个1201发给对方，再次请求1201这个包。如果出现了3次就说明现在的网络状况其实有点糟糕，但是没那么糟糕，直接设置为阈值一半进入快速恢复状态。
  • 快速恢复：在快速回复中，对于引起TCP进入快速回复的状态的缺失报文段，对收到的每一个冗余的ACK，cwnd的值会增加一个MSS。最终当对丢失的报文的一个ACK到达时，TCP在降低cwnd后进入拥塞避免的而状态。如果出现超时时间，快速恢复在执行如同在慢启动和拥塞避免中相同的动作后，迁移到慢启动的状态。当丢包时间出现后，cwnd会变成1，ssthresh的值变成cwnd的一半。其实看到这里我还是很懵逼，不过你只要把丢包情况分为2中，冗余ACK和超时丢包就好理解一点。超时丢包是很严重的丢包情况，如果受到冗余的ACK说明后面的包还是过去了，如果这个都没受到，只能说明后面的包还是没过去。你根本不知道前面堵车多严重，所以直接重置cwnd是最好的选择。而受到冗余的ACK说明可能是而然的丢包了，或者可能只是堵了一点点。而后面的ACK受到说明是没问题。所以这个时候只需要从cwnd/2启动即可。

如果觉得写的还行请点个赞把xdm，之后就可以继续更新其他的计算机网络相关知识了，xdm！p！l！z！