计算机网络常见问题
传输层协议
q1 tcp的握手过程
tcp网络的握手过程分为3次，正如大多数博客所讲的基础过程也就是浏览器（client）发送请求到服务器（server），然后server返回client，然后在client在返回server。如下图
但面对这么过程中有许多的细节，例如为什么是3次，选择序列号有什么讲究等问题。
首先来tcp是一个稳定的传输协议，它的稳定性依赖于arq协议，那么对于后面的过程来说，确定端对端能否交流就是一个重要的过程，3次握手协议意义在此。
<font color='red'>通俗来说：</font>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的。这样三次握手，就达到了双方互相知道的效果。）
当然如果你想表达<font color='red'>更加专业点:</font>tcp的3次连接是一个双工过程。这个术语我最先从操作系统的通信机制中了解到的，父进程与子进程通过匿名管道进行半双工过程通信。而这种情况下，他们只需要一端能用即可。而在tcp的过程中需要read和write都能用，所以3次握手是最快能确认tcp能够进行双工通信的方式。
q2 tcp的挥手过程
tcp的4次挥手过程如下图
无论理解挥手还是握手问题，最主要的是分析端与端之间的双工过程，4次挥手与握手相反，他是一个关闭过程。
- 在第一次挥手过程中client会选择请求关闭连接.
- server收到后，必须马上回复消息给client，以便让他知道此次的请求没有丢失。
- client收到后，就知道请求以及送达不会重发。
- server完成最后的数据传输。
- 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端发生意想不到的错误。
如果觉得写的还行请点个赞把xdm，之后就可以继续更新其他的计算机网络相关知识了，xdm！p！l！z！
