网络协议精讲-优快云博客

本文链接：https://blog.youkuaiyun.com/sumatch/article/details/118388632

一. 网络分层

在这里插入图片描述

数据报在

传输层加远端口号和目的端口号;
在网络层加上原ip和目的ip ;
在数据链路层转化成数据桢进行校验;
在物理层变成信号(电、光、等信号)发送出去。

1.1 应用层

应用层指能够产生网络流量且能够和用户交互的应用程序。

应用层协议定义了应用进程的通信规则，应用进程互相通信完成网络应用。

包括：

域名解析系统 DNS

DNS 是一个分布式数据库系统，存储了域名和 IP 地址的映射关系。

主机向本地域名服务器的查询采用递归查询：如果本地域名服务器不知道被查询域名的 IP 地址，就会以 DNS 客户的身份向其他根域名服务器继续发出查询请求。

本地域名服务器向根域名服务器查询采用迭代查询：根域名服务器会告知顶级域名服务器的地址，顶级域名服务器给出 IP 地址，或者告知下一步应该向哪个权限域名服务器进行查询。
文件传送协议 FTP

FTP 通过TCP 保证可靠运输，使用两个端口: 控制端口 21 和数据端口 20，分别进行控制连接和数据连接。
电子邮件协议

从用户代理把邮件传送到服务器，以及在服务器之间的传送使用 SMTP 协议。

用户代理从服务器读取邮件时使用 POP3 或 IMAP 协议。

1.2 传输层

传输层负责向主机应用进程间的通信提供数据传输服务，由于一台主机可以同时运行多个进程，因此传输层具有复用和分用的功能：

复用就是多个应用进程可以同时使用传输层发送数据
分用就是把传输层收到的数据交付给对应的应用进程。

运输层协议包括：

UDP 用户数据报协议：提供无连接的、尽最大的交付的数据传输服务，不保证可靠性，传输单位是用户数据报。
TCP 传输控制协议：提供面向连接的数据传输服务、保证可靠性，传输单位是报文。

1.3 网络层

网络层任务：

为分组交换网上的主机提供通信服务，在发送数据时把运输层数据报封装成分组传送。
选择合适路由，使源主机的分组通过路由器找到目的主机。

网络层协议包括：

网际协议 IP

一般指 IPv4，与 IP 配套使用的还有 ARP、ICMP 和 IGMP。

IP 数据报分为首部和数据两部分。首部前 20 字节是固定的，包含源地址、目的地址、总长度等，生存时间限制了 IP 数据报在网络中能经过的最大路由数，防止其兜圈子。

要解决 IP 地址耗尽的问题，根本方法是采用具有更大地址空间的 IPv6（128 位）。

IP数据报的最大长度是65535个字节。
地址解析协议 ARP

由于 IP 使用了 ARP，因此把 ARP 归到网络层。

简单理解ARP就是查 ip-mac 地址映射表。

与 ARP 对应的是 RARP 逆地址解析协议，作用是通过硬件地址找到 IP 地址，被 DHCP 协议取代。
路由选择协议

内部网关协议：
- RIP：分布式的距离向量协议，适用于小型网络，按固定时间间隔与相邻路由器交换路由表信息。
- OSPF：分布式的链路状态协议，适用于大型网络，只在链路状态变化时才向本自治系统中的所有路由器发送相邻路由器的信息。
外部网关协议：
- BGP-4：针对不同自治系统之间的路由器，目标是寻找一条能够到达目的网络且不兜圈子的路由。
网际控制报文协议 ICMP

它是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
网际组管理协议 IGMP

IGMP 的作用是让连接在本地局域网上的多播路由器知道本局域网上是否有主机的某个进程参加或退出了某个多播组。

1.4 链路层

数据链路层将网络层的分组封装成帧，在两个相邻结点间的链路上传输，每一帧包括数据和必要的控制信息（同步信息、地址信息、差错信息）。控制信息使接收端能够知道一个帧从哪个比特开始到哪个比特结束，从帧中提取出数据上交给网络层。控制信息还使接收端可以检测收到的帧有无差错，如果有差错就简单地丢弃，避免继续传送而浪费网络资源。

链路层协议包括：

点对点协议 PPP

在通信质量较差的年代使用高级数据链路控制 HDLC 作为数据链路层协议，目前使用最广泛的协议是 PPP。PPP 的特点是简单、只检测差错而不纠正、不使用序号也不进行流量控制、同时支持多种网络层协议。
CSMA/CD 协议

以太网采用具有冲突检测的载波监听多点接入协议，特点是：发送前先监听、边发送边监听，一旦发现总线上出现了碰撞就立即停止发送，然后按退避算法等待一段随机时间后再次发送。
自动重传请求 ARQ

自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一，包括停止等待协议、回退 N 步协议和选择重传协议，后两种结合了窗口机制，属于连续 ARQ 协议。

1.5 物理层

物理层的数据单位是比特，发送方和接收方发送和接收 1 或 0，因此物理层需要考虑用多大的电压代表 1 或 0，以及接收方如何识别发送方所发送的比特。此外物理层还要确定传输媒体规范，例如接线器形状、电缆电压范围等。

二. TCP

2.1 TCP 特点

TCP 是面向连接的，一个应用进程在向另一个进程发送数据前必须先建立连接，发送某些预备报文段。
TCP 提供全双工服务，允许通信双方的应用进程在任何时候发送数据。TCP 连接的两端都有发送缓存和接收缓存：发送时，应用程序把数据传送给 TCP 缓存后就可以做自己的事，TCP 在合适的时候发送；接收时，TCP 把收到的数据放入缓存，应用程序在合适的时候读取。
TCP 连接是点对点的，只能在单个发送方和单个接收方之间的连接。
TCP 提供可靠的交付服务，通过 TCP 传送的数据无差错、不丢失、不重复，按序到达。
TCP 是面向字节流的，流是指流入进程或从进程流出的字节序列。虽然应用程序和 TCP 的交互是每次一个数据块，但 TCP 把数据块仅看成一连串无结构的字节流。TCP 不保证接收方的数据块和发送方的数据块具有对应大小的关系，但接收方的字节流必须和发送方的字节流完全一样。应用程序必须有能力识别收到的字节流，把它还原成应用层数据。

2.2 TCP 和 UDP 的区别？

1.TCP（面向字符流）

传递任意长度
可靠
流量控制
拥塞控制

2.UDP（面向报文）

一对多通讯
效率高
简单
实时性好
无阻塞问题

2.3 TCP 报文结构

在这里插入图片描述

源端口地址和目标端口地址

标识发送方和接收方应用程序端口号。TCP 的分用功能是通过端口实现的。
序号

定义了指派给本报文第一个数据字节的编号。
确认号（ack）

定义了接收方期望从对方接收的字节编号。确认号为 N 代表到 N-1 为止都已收到。
HLEN：Head Length 首部长度

指出首部一共有多少个4字节。首部长度可以在20~60个字节之间，因此这个字段的值可以在5(5 x 4 = 20) ~ 15(15 x 4 = 60)之间
保留

这是一个6位字段，保留为今后使用
控制：这个字段定义了6种不同的控制位或标志，可以同时设置1位或多位标志。这些标志用在TCP的流量控制、连接建立和终止、连接异常终止以及数据传送方式等方面。
- URG：紧急，URG=1 时表示存在紧急数据，不再排队等待发送，需要和紧急指针配合使用。
- ACK：确认，ACK=1 时表示成功接收了报文段。
- PSH：推送，PSH=1 时接收方不再等待整个缓存填满再交付数据，而是尽快交付数据。
- RST：复位，当 RST=1 时表示 TCP 连接出现了严重错误，必须释放再重新建立连接。
- SYN：同步，在建立连接时用来同步序号，SYN=1 表示一个连接请求或连接响应报文。
- FIN：终止，用来释放连接，当 FIN=1 时表示发送方已发送完毕，并要求释放连接。
窗口尺寸

发送方TCP窗口的大小，以字节为单位。这个字段是16位的，也就是说窗口的最大长度为65535个字节，这个值由接收方来决定，这种情况下发送方必须服从接收方的指示。因为接收方的缓存有限。
检验和

检验包括首部和数据两部分，如果接收方检测到差错会丢弃 TCP 报文。

2.4 TCP 的三次握手机制

TCP 是全双工通信，任何一方都可以发起连接请求，假设 A 是客户端，B 是服务器。

初始 A 和 B 均处于 CLOSED 状态，B 会创建传输进程控制块 TCB 并进入 LISTEND 状态，监听端口是否收到连接请求。
当 A 要发送数据时，就向 B 发送连接请求报文，其中 SYN=1, ACK=0，SYN 不可以携带数据，但要消耗一个序号（假设 seq=x）。发送后 A 进入 SYN-SENT 同步已发送状态。
当 B 收到 A 的连接请求报文后，进入 SYN-RCVD 同步已接收状态，如果同意建立连接就会发送给 A 一个连接响应报文，其中 SYN=1, ACK=1, ack=x+1, seq=y。ack 的值为 A 发送的序号加 1，ACK 可以携带数据，如果不携带的话则不消耗序号。
当 A 收到 B 的确认后，还要对该确认再进行一次确认，发送报文 ACK=1, ack=y+1, seq=x+1，发送后 A 进入 ESTABLISHED(已确认) 状态，当 B 接收到该报文后也进入 ESTABLISHED 状态，客户端会稍早于服务器端建立连接。

2.4.1 为什么要三次握手

报文的生存时间往往会超过 TCP 请求的超时时间，A 的某个超时连接请求可能会在双方释放连接后到达 B，B 会误以为是 A 创建了新的连接请求，然后发送确认报文创建连接。由于 A 的状态不是 SYN_SENT，将直接丢弃 B 的确认数据。如果是两次握手，连接建立，服务器资源被白白浪费；如果是三次握手，B 由于长时间没有收到确认，最终超时导致连接失败，不会出现脏连接。

2.5 TCP 四次挥手

当 A 没有要发送的数据时就会向 B 发送终止连接报文，其中 FIN=1, seq=u，u 的值为之前 A 发送的最后一个序号加 1，发送后 A 进入 FIN-WAIT-1 状态。

客户端发送第一次挥手后，就不能在向服务端发送数据了。
B 收到后响应给 A 一个确认报文，ACK=1, ack=u+1, seq=v，v 的值为 B 之前发送的最后一个序号加 1。此时 A 进入 FIN-WAIT-2 状态，B 进入 CLOSE-WAIT 状态，但连接并未完全释放，B 会通知应用进程结束 A 到 B 方向的连接，此时 TCP 处于半关闭状态。

Server 第一次响应后，还可以继续向 Client 发送数据，这里只是告诉 Client ，我收到你发送的关闭请求。
当 B 也准备释放连接时就向 A 发送连接终止报文，FIN=1，同时还要重发 ACK=1, ack=u+1, seq=w，seq 改变的原因是在半关闭状态 B 可能又发送了数据，之后 B 进入 LAST-ACK 状态。

当 Server 的数据响应完成后，再告诉 Client，我这边也可以关闭请求了，此时Server 就不能再向 Client 发送数据了
A 收到连接终止报文后还要再进行一次确认，确认报文中 ACK=1, ack=w+1, seq=u+1，发送完后进入 TIME-WAIT 状态，等待 2MSL 后进入 CLOSED 状态。B 收到该确认后进入 CLOSED 状态，服务器端会稍早于客户端释放连接。

2.5.1 四次挥手原因？

TCP 是全双工通信，两个方向的连接需要单独断开。

为什么关闭连接的需要四次挥手，而建立连接却只要三次握手呢？

关闭连接时，被动断开方在收到对方的FIN结束请求报文时，很可能业务数据没有发送完成，并不能立即关闭连接，被动方只能先回复一个ACK响应报文，告诉主动断开方：“你发的FIN报文我收到了，只有等到我所有的业务报文都发送完了，我才能真正的结束，在结束之前，我会发你FIN+ACK报文的，你先等着”。所以，被动断开方的确认报文，需要拆开成为两步，故总体就需要四步挥手。

而在建立连接场景中，Server端的应答可以稍微简单一些。当Server端收到Client端的SYN连接请求报文后，其中ACK报文表示对请求报文的应答，SYN报文用来表示服务端的连接也已经同步开启了，而ACK报文和SYN报文之间，不会有其他报文需要发送，故而可以合二为一，可以直接发送一个SYN+ACK报文。所以，在建立连接时，只需要三次握手即可。

为什么连接建立的时候是三次握手，可以改成两次握手吗？

三次握手完成两个重要的功能：一是双方都做好发送数据的准备工作，而且双方都知道对方已准备好；二是双方完成初始SN序列号的协商，双方的SN序列号在握手过程中被发送和确认。

如果把三次握手改成两次握手，可能发生死锁。两次握手的话，缺失了Client的二次确认ACK帧，假想的TCP建立的连接时二次挥手，可以如下图所示：
在这里插入图片描述
在假想的TCP建立的连接时二次握手过程中，Client发送Server发送一个SYN请求帧，Server收到后发送了确认应答SYN+ACK帧。按照两次握手的协定，Server认为连接已经成功地建立了，可以开始发送数据帧。这个过程中，如果确认应答SYN+ACK帧在传输中被丢失，Client没有收到，Client将不知道Server是否已准备好，也不知道Server的SN序列号，Client认为连接还未建立成功，将忽略Server发来的任何数据分组，会一直等待Server的SYN+ACK确认应答帧。而Server在发出的数据帧后，一直没有收到对应的ACK确认后就会产生超时，重复发送同样的数据帧。这样就形成了死锁。

2.5.2 等待 2MSL 的原因：

保证被动关闭方可以进入 CLOSED 状态。MSL 是最大报文段寿命，等待 2MSL 可以保证 A 发送的最后一个确认报文被 B 接收，如果该报文丢失，B 会超时重传之前的 FIN+ACK 报文，而如果 A 在发送确认报文后立即释放连接就无法收到 B 可能超时重传的报文，也不会再次发送确认报文段，B 就无法正常进入 CLOSED 状态。
2MSL 时间后，本连接中的所有报文就都会从网络中消失，防止已失效连接的请求数据包与正常连接的请求数据包混淆而发生异常。

除此之外，TCP 还设有一个保活计时器，用于解决客户端故障问题，服务器每收到一次数据就重新设置保活计时器，如果 2 小时内没有收到数据就间隔 75 秒发送一次探测报文，连续 10 次没有响应后关闭连接。

2.6 TCP 如何保证传输可靠性

TCP 的可靠传输包含很多机制，例如使用检验和来检测传输中的比特错误、使用定时器超时重传、使用序号检测丢失分组和冗余副本、使用确认号告诉发送方确认的分组信息。

2.6.1 校验和

发送的数据包的二进制相加然后取反，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。

2.6.2 确认应答+序列号

TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
在这里插入图片描述

2.6.3 超时重传

当TCP发出一个段后，它启动一个定时器(一般是0.5秒的整数倍)**，等待目的端确认收到这个报文段。**如果不能及时收到一个确认，将重发这个报文段。

2.6.4 流量控制

TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。

TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。

2.6.5.阻塞控制

网络中对资源的需求超过可用量的情况就叫拥塞，当吞吐量明显小于理想吞吐量时就出现了轻度拥塞。拥塞控制就是减少注入网络的数据，减轻路由器和链路的负担，这是一个全局性问题，涉及网络中的所有路由器和主机，而流量控制是一个端到端的问题。

如何判断网络拥塞？

通过观察网络的吞吐量与网络负载间的关系
服务器检测心跳，客户端每隔一段时间会发送心跳报文给服务器，服务器对心跳时间进行检测。
服务器发送数据给客户端，累计发送不出去的次数。

拥塞控制主要是四个算法：1）慢启动，2）拥塞避免，3）拥塞发生，4）快速恢复。

慢启动机制：在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。
**拥塞避免机制：**一旦进入拥塞避免状态，cwnd 值大约是上次拥塞时的 1/2，距离拥塞并不遥远。因此 TCP 不会每经过一个 RTT 就将 cwnd 翻倍，而是较为保守地在每个 RTT 后将 cwnd 加 1。

发生超时事件时，拥塞避免和慢启动一样，将 cwnd 设为 1，并将慢启动阈值设置为 cwnd/2。
**快恢复机制：**有时个别报文段丢失，但网络中并没有出现拥塞，如果使用慢启动会降低传输效率。这时应该使用快重传来让发送方尽早知道出现了个别分组的丢失，快重传要求接收端不要等待自己发送数据时再捎带确认，而是要立即发送确认。即使收到了乱序的报文段也要立即发出对已收到报文段的重复确认。当发送方连续收到三个冗余 ACK 后就知道出现了报文段丢失的情况，会立即重传并进入快恢复状态。

在快恢复中，会调整慢启动阈值为 cwnd/2，并进入拥塞避免状态。

2.6.6 滑动窗口

TCP的滑动窗口协议有什么意义呢？

**可靠性：**滑动窗口只有在队列前部的被确认之后，才会往后移动，保证数据包被接收方确认并接收。
**传输效率：**假如没有窗口，服务端是杂乱无章地进行发包，因为TCP的队首效应，如果有前面的包没有发送成功，就会不停的重试，反而造成更差的传输效率。
**稳定性：**TCP的滑动窗口大小，是整个复杂网络商榷的结果，会进行动态调整，可以尽量地避免网络拥塞，更加稳定。

滑动窗口以字节为单位。发送端有一个发送窗口，窗口中的序号是允许发送的序号，窗口的后沿是已发送且确认的序号，窗口的前沿是不允许发送的序号。窗口的后沿可能不动（没有收到新的确认），也有可能前移（收到了新的确认），但不会后移（不可能撤销已经确认的数据）。窗口的前沿一般是向前的，可能不动（没有收到新的请求或对方的接收窗口变小），也可能收缩（TCP 强烈不建议这么做，因为发送端在收到通知前可能已经发送了很多数据，将产生错误）。

发送缓存存放应用程序传给 TCP 准备发送的数据和已发送但还未确认的数据；接收缓存存放按序到达但尚未被应用程序读取的数据和未按序到达的数据。

规则：