协议 - 咖啡猫

本文最后更新于：星期一, 九月 12日 2022, 1:25 凌晨

OSI七层协议

物理层: 利用传输介质为数据链路层提供物理连接，实现比特流的透明传输
数据链路层: 负责建立和管理节点间的链路
网络层: 通过路由选择算法，为报文或分组通过通信子网选择最适当的路径
传输层: 向用户提供可靠的端到端的差多和流量控制，保证报文的正确传输
会话层: 向两个实体的表示层提供建立和使用连接的方法
表示层: 处理用户信息的表示问题，如编码、数据格式转换和加密解密等
应用层: 直接向用户提供服务，完成用户希望在网络上完成的各种工作

七层各自描述和包含的协议见下图

描述和包含的协议

TCP/IP四层协议

数据链路层: 对应OSI的物理层和数据链路层
网络层: 对应OSI的网络层
传输层: 对应OSI的传输层
应用层: 对应OSI的会话、表示、应用层

对应关系如图

TCP和UDP

传输层的TCP和UDP是面试常问问题

TCP: 传输控制协议（Transmission Control Protocol），提供面向连接、可靠的数据传输服务
UDP: 用户数据协议（User Datagram Protocol），提供无连接，尽最大努力的数据传输服务（不保证数据传输的可靠性）

对比

如图

TCP提供面向连接服务，传送数据前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。TCP由于在传数据之前，用三次握手来建立连接，传数据过程中有确认、窗口、重传、拥塞控制等级制，传完还会四次挥手断开连接来节约系统资源，因此相对可靠，但是这会增加许多开销，不但使协议数据单元首部大很多，而且还占用了很多资源。它一般用在文件传输、发送、接收邮件、远程登录等场景

UDP相对没那么多事情，传数据前不需要建立连接、远程主机收到报文后也不需要给出任何确认。它不保证数据传输可靠性，但在语音、视频聊天和直播等属于即时通信场景的情况下，确是一种最有效的工作方式。

TCP三次握手

三次握手

如图依次说明

由于全双工模式（Full Duplex，通讯传输的一个术语。允许数据在两个方向上同时传输，可以同时进行A→B且B→A），最开始时客户端和服务器都处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器

TCP服务器进程先创建传输控制块TCB（Transmission Control Block），时刻准备接受客户端进程的连接请求，此时服务器就进入了LISTEN（监听）状态
TCP客户端进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号
TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号
TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号
当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了

三大疑问？

为啥要三次握手？不能两次么？

三次握手目的是建立可靠的通信通道，让建立通道的双方确认自己与对方的数据发送、接收功能都是正常的。

第一次握手: 客户端什么都确认不了，服务器确认对方发送正常，自己接收正常
第二次握手: 客户端确认自己发送、接收正常，对方发送、接收正常，服务器确认对方发送正常，自己接收正常
第三次握手：客户端确认自己发送、接收正常，对方发送、接收正常，服务器确认自己发送、接收正常，对方发送、接收正常

所以三次握手能确认双方收发功能都正常，缺一不可啊~

如果还不能理解，举个栗子吧

假设你刚入职了一家公司，在微信上加了个漂亮女同事微信，你向她发微信打招呼

两次握手只能保证单向连接是畅通的
握手1 你 -> 漂亮女同事: 你好啊，美女
握手2 你<- 漂亮女同事: 嗯。你也好啊，帅哥
这样一来一回，就等于握了两次手，你向女同事发微信并得到了回复，即你向女同事发送了微信消息，她是可以收到的。但是漂亮女同事向你发微信，你却还没回复，她没有收到你的回复，无法确认你是否收到了她发送的微信消息
只有经过第三次握手，才能确保双向都可接收到对方发送的数据。
握手3 你 -> 漂亮女同事: 收到，美女。以后请多指教
这样女同事才能确定你也可以收到她发给你的微信消息

为啥服务器要传回SYN？

服务器传回客户端SYN，只是为了告诉客户端，我收到的信息的的确确是你发送的信号。

SYN是建立连接时使用的握手信号。客户端和服务器建立TCP连接时，客户端先发SYN消息，服务器使用SYN-ACK应答表示接收到这个消息，最后客户端再以ACK（acknowledgement）响应。这样客户端和服务器才能建立可靠的TCP连接。这个ACK有点相当于你去便利店买东西，营业员给你的小票，确认你已购买过小票上的商品，并有总计价格。

传了SYN，为啥还要传ACK？

传了SYN只是证明客户端到服务器的通道没问题，但是服务器到客户端的通道还需要ACK信号来验证。

TCP四次挥手

四次挥手

如图依次说明

数据传输完，双方都可释放连接。最开始时，客户端和服务器都处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1）。此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号
服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器最后发送的数据）
服务器将最后的数据发送完，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些

这次疑问是两个

为啥挥手一定要四次？

任何一方都可以在数据传送结束后发出连接释放的通知，等待对方确认后进入半关闭状态。当另一方也再没有数据发送时，就会发出连接释放通知，对方确认后才会完全关闭TCP连接

还是举个栗子吧

你和你女友约会结束，你把她送到她家楼下，然后准备各回各家时，你说:”今天就到这里吧，我回家了”，你女友说：“哦，我知道了”。但是看她样子可能还想和你呆一会儿，还想说几句话，你总不能说回家就回家，让她跟着你节奏吧？于是你女友可能又和你呆了一会儿，说了一会儿话，最后她也累了，就说:“那我上楼了”，这时你回答“好，再见”，这样才算一次约会结束

这个MSL是什么鬼？为啥客户端最后还要等待2*MSL这段时间？

MSL（Maximum Segment Lifetime）。最大报文生命时间。TCP允许不同的实现可以设置不同的MSL值。

保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我响应，应该是我发送的请求断开报文它没收到，于是服务器又会重新发一次，而客户端就能在这个2* MSL时间段内收到这个重传的报文，接着给出响应报文，并会重启2MSL计时器
如果已关闭的老连接和新连接端口号一样，再加上正好碰到老连接的某些数据仍然还滞留在网络中，那么TCP会认为这些滞留数据是新连接的，这就会发生报文混淆。因此为了防止滞留数据出现在新连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，可使本次老连接持续时间内，所产生的所有报文段都从网络中消失。这样新连接中就不会出现老连接的请求报文

协议