1.UDP（即用户数据报协议）

UDP是一种无连接的传输层协议，提供简单的、不可靠的数据传输服务。它不保证数据包的顺序、可靠性或重复性，但具有低延迟和高效率的特点。

UDP协议段格式

16位UDP⻓度,表⽰整个数据报(UDP⾸部+UDP数据)的最⼤⻓度，也就是64kb可是现在的互联网中已经不够用了
如果校验和出错,就会直接丢弃

理解UDP的不可靠（即传输控制协议）

UDP 的不可靠体现在它无法保证数据能 “完整、有序、不重复” 地到达接收方，且出现问题时不会主动处理或通知。

无连接：跳过 “通信准备” 环节，发送方无需向接受方发起连接，直接进行传输
无确认与重传机制：“发完即忘”，接收方未确认收到，可能数据丢失发送法也不知道也不会进行重传
无序传输：不保证数据顺序，没有序号标记，数据报可能通过不同的路径进行传输，接受方获取乱序的数据
无去重机制：可能收到重复数据，可能因为网络问题导致接收方重复接受数据报
可选的校验和：对数据损坏的处理有限，UDP的校验和是可选的，如果出错会直接丢弃
无流量控制与拥塞控制：“不管网络死活”，若大量数据包发送造成网络堵塞可能数据报会发生丢弃

2.TCP

TCP（Transmission Control Protocol）是传输层协议，提供面向连接、可靠的数据传输服务。

TCP协议段格式

TCP 头部字段详解

源/目的端口号

表示数据从哪个进程发送，到哪个进程接收。端口号用于标识主机上的具体应用进程。

32位序号/32位确认号

序号用于标识数据包的顺序，确保数据按序传输。
确认号用于确认接收到的数据，表示期望接收的下一个字节序号。

4位TCP报头长度

表示TCP头部包含的32位字的数量。
头部最大长度为15 × 4 = 60字节（因为4位最大值为15）。

6位标志位

URG：紧急指针是否有效。若为1，表示紧急数据需要优先处理。
ACK：确认号是否有效。若为1，表示确认号字段有意义。
PSH：提示接收端应用程序立即从TCP缓冲区读取数据。
RST：表示要求重新建立连接。携带RST标志的报文称为复位报文段。
SYN：请求建立连接。携带SYN标志的报文称为同步报文段。
FIN：通知对方本端要关闭连接。携带FIN标志的报文称为结束报文段。

16位窗口大小

表示接收端的接收缓冲区剩余空间大小，用于流量控制。

16位校验和

由发送端填充，采用CRC校验算法。
校验范围包括TCP头部和数据部分。接收端校验失败则丢弃数据。

16位紧急指针

当URG标志为1时有效，指向紧急数据的末尾位置。

40字节头部选项（可选字段）

用于扩展TCP功能，如最大报文段长度（MSS）、窗口缩放因子等。

TCP的可靠

确认应答

在上述我们说过UDP的不可靠而TCP却恰恰相反。

每⼀个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下⼀次你从哪⾥开始发送

超时重传

主机A发送数据给B之后,可能因为⽹络拥堵等原因,数据⽆法到达主机B
如果主机A在⼀个特定时间间隔内没有收到B发来的确认应答,就会进⾏重发; 但是,主机A未收到B发来的确认应答,也可能是因为ACK丢失了

因此主机B会收到很多重复数据.那么TCP协议需要能够识别出那些包是重复的包,并且把重复的丢弃掉

超时的时间如何确定?

最理想的情况下找个最小的时间，但是网络通信的复杂程度哪有这么容易获取呢，时间太长影响效率，时间太短重复发送。因此TCP为了保证⽆论在任何环境下都能⽐较⾼性能的通信,因此会动态计算这个最⼤超时时间。

超时以500ms为⼀个单位进⾏控制,每次判定超时重发的超时时间都是500ms的整数倍.
如果重发⼀次之后,仍然得不到应答,等待2*500ms后再进⾏重传.
如果仍然得不到应答,等待4*500ms进⾏重传.依次类推,以指数形式递增.
累计到⼀定的重传次数,TCP认为⽹络或者对端主机出现异常,强制关闭连接

连接管理

在正常情况下,TCP要经过三次握⼿建⽴连接,四次挥⼿断开连接

CLOSED：初始 “关闭” 状态，连接未建立或已完全关闭，无任何连接相关资源占用。
LISTEN（仅服务器）：服务器调用 listen() 后进入，处于 “监听” 状态，等待客户端发起连接请求。
SYN_SENT（仅客户端）：客户端调用 connect() 发送 SYN（同步连接请求）后进入，等待服务器响应 SYN+ACK。
SYN_RCVD（仅服务器）：服务器收到客户端 SYN 后进入，已准备好响应 SYN+ACK，等待客户端最终 ACK。
ESTABLISHED（客户端 + 服务器）：三次握手完成后进入，连接 “已建立” 状态，双方可正常收发数据。
FIN_WAIT_1（仅客户端）：客户端主动调用 close() 发送 FIN（结束连接请求）后进入，等待服务器 ACK。
FIN_WAIT_2（仅客户端）：客户端收到服务器对 FIN 的 ACK 后进入，等待服务器发起 FIN 关闭请求。
CLOSE_WAIT（仅服务器）：服务器收到客户端 FIN 后进入，需处理自身关闭逻辑（如收尾数据），准备主动发 FIN。
LAST_ACK（仅服务器）：服务器发送 FIN 后进入，等待客户端最终 ACK 确认关闭。
TIME_WAIT（仅客户端）：客户端发送对服务器 FIN 的 ACK 后进入，需等待超时（避免报文丢失导致连接残留），超时后彻底关闭。

TCP 三次握手（建立连接）

三次握手的目的是同步通信双方的序列号，并确认彼此的接收和发送能力，最终建立可靠的连接。

过程详解

第一次握手（客户端 → 服务器）
- 客户端向服务器发送 SYN（同步）报文，请求建立连接。
- 报文包含：客户端的初始序列号（seq = x），表示后续数据将从 x+1 开始发送。
第二次握手（服务器 → 客户端）
- 服务器收到 SYN 后，同意建立连接，回复 SYN+ACK（同步 + 确认）报文。
- 报文包含：
  - 服务器的初始序列号（seq = y）；
  - 确认号（ack = x+1），表示已收到客户端的 x 序号，期待下一个数据从 x+1 开始。
第三次握手（客户端 → 服务器）
- 客户端收到 SYN+ACK 后，发送 ACK（确认）报文。
- 报文包含：确认号（ack = y+1），表示已收到服务器的 y 序号，期待下一个数据从 y+1 开始。
- 服务器收到 ACK 后，连接正式建立，双方开始传输数据。

其实这里就像两个人通电话：

甲打给乙：喂，你能听到吗？（甲发起连接请求）
乙回应：能听到！你能听到我吗？（乙确认收到，同时反问甲）
甲回答：能听到！那我们开始说吧。”（甲确认收到乙的回应）

TCP 四次挥手（终止连接）

过程详解：

假设客户端先主动关闭连接：

第一次挥手（客户端 → 服务器）
- 客户端发送 FIN（结束）报文，表示 “我不再发送数据了”。
- 报文包含：客户端当前序列号（seq = u）。
第二次挥手（服务器 → 客户端）
- 服务器收到 FIN 后，回复 ACK 报文，确认 “已收到关闭请求”。
- 报文包含：确认号（ack = u+1），服务器自身序列号（seq = v）。
- 此时，客户端到服务器的方向连接关闭，但服务器仍可向客户端发送数据（半关闭状态）。
第三次挥手（服务器 → 客户端）
- 服务器发送完所有数据后，也发送 FIN 报文，表示 “我也不再发送数据了”。
- 报文包含：服务器当前序列号（seq = w，w 可能大于 v，因期间可能发送了数据），确认号（ack = u+1）。
第四次挥手（客户端 → 服务器）
- 客户端收到 FIN 后，回复 ACK 报文，确认 “已收到服务器的关闭请求”。
- 报文包含：确认号（ack = w+1），客户端自身序列号（seq = u+1）。
- 服务器收到 ACK 后，关闭连接；客户端需等待一段时间（2MSL，确保服务器收到 ACK）后关闭连接。

这里就像有一方想挂电话的场景：

甲说：我说完了，要挂了哦。（甲请求关闭连接）
乙回应：好，知道你要挂了，我这边还有点话没说完。（乙确认收到，但没准备好）
乙补完话说：我也说完了，你可以挂了。（乙准备好关闭）
甲回应：好，那挂了。（甲确认，最终断开）

滑动窗⼝

窗⼝⼤⼩指的是⽆需等待确认应答⽽可以继续发送数据的最⼤值.上图的窗⼝⼤⼩就是4000个字节，收到第一个ASK的时候继续发送以此类推。这样的话同时也伴随着问题。

情况⼀:数据包已经抵达,ACK被丢了

这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进⾏确认;

情况⼆:数据包就直接丢了

当中间有一段数据段丢失了，接收方就会一直1001ACK重复应答，接收方就收到重复的1001ACK的确认应答，则进行重发，再次收到就是7001ACK，因为之前已经发送过了只是因为丢失进入了接收缓冲区

流量控制

接收端处理数据的速度是有限的.如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继⽽引起丢包重传等等⼀系列连锁反应.

因此TCP⽀持根据接收端的处理能⼒,来决定发送端的发送速度.这个机制就叫做流量控制

接收端将⾃⼰可以接收的缓冲区⼤⼩放⼊TCP⾸部中的"窗⼝⼤⼩"字段,通过ACK端通知发送端;

这里的缓冲区可以看出一杯水，满了就不能再加了，需要喝水，取决于你喝多少水，我就加多少水。

窗⼝⼤⼩字段越⼤,说明⽹络的吞吐量越⾼;
接收端⼀旦发现⾃⼰的缓冲区快满了,就会将窗⼝⼤⼩设置成⼀个更⼩的值通知给发送端;
发送端接受到这个窗⼝之后,就会减慢⾃⼰的发送速度;
如果接收端缓冲区满了,就会将窗⼝置为0;这时发送⽅不再发送数据,但是需要定期发送⼀个窗⼝探测数据段,使接收端把窗⼝⼤⼩告诉发送端.

拥塞控制

虽然TCP有了滑动窗⼝这个⼤杀器,能够⾼效可靠的发送⼤量的数据.但是如果在刚开始阶段就发送⼤量的数据,仍然可能引发问题.

因为⽹络上有很多的计算机,可能当前的⽹络状态就已经⽐较拥堵.在不清楚当前⽹络状态下,贸然发送⼤量的数据,是很有可能引起雪上加霜的.

TCP引⼊慢启动机制,先发少量的数据,探探路,摸清当前的⽹络拥堵状态,再决定按照多⼤的速度传输数据;

此处引⼊⼀个概念程为拥塞窗⼝
发送开始的时候,定义拥塞窗⼝⼤⼩为1
每次收到⼀个ACK应答,拥塞窗⼝加1
每次发送数据包的时候,将拥塞窗⼝和接收端主机反馈的窗⼝⼤⼩做⽐较,取较⼩的值作为实际发送的窗⼝

像上⾯这样的拥塞窗⼝增⻓速度,是指数级别的."慢启动"只是指初使时慢,但是增⻓速度⾮常快，为了不增⻓的那么快,因此不能使拥塞窗⼝单纯的加倍

此处引⼊⼀个叫做慢启动的阈值
当拥塞窗⼝超过这个阈值的时候,不再按照指数⽅式增⻓,⽽是按照线性⽅式增⻓
当TCP开始启动的时候,慢启动阈值等于窗⼝最⼤值
在每次超时重发的时候,慢启动阈值会变成原来的⼀半,同时拥塞窗⼝置回1

延迟应答

指接收方收到数据后，不立即返回确认（ACK）报文，而是短暂延迟一段时间（通常不超过 500ms），等待是否有其他数据或控制信息可以与 ACK “合并” 发送（例如结合捎带应答机制），从而减少网络中单独 ACK 报文的数量，降低带宽消耗。

假设接收端缓冲区为1M.⼀次收到了500K的数据;如果⽴刻应答,返回的窗⼝就是500K;
但实际上可能处理端处理的速度很快,10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下,接收端处理还远没有达到⾃⼰的极限,即使窗⼝再放⼤⼀些,也能处理过来;
如果接收端稍微等⼀会再应答,⽐如等待200ms再应答,那么这个时候返回的窗⼝⼤⼩就是1M;

延迟应答的限制

数量限制:每隔N个包就应答⼀次;

时间限制:超过最⼤延迟时间就应答⼀次;

具体的数量和超时时间,依操作系统不同也有差异;⼀般N取2,超时时间取200ms

捎带应答

指发送方在向接收方传输数据报文时，顺便将对之前已接收数据的确认（ACK）信息 “捎带” 在该数据报文中，而非单独发送一个 ACK 报文。这一机制的核心目的是减少网络中报文的数量，降低带宽消耗，提高通信效率。

⾯向字节流

创建⼀个TCP的socket,同时在内核中创建⼀个发送缓冲区和⼀个接收缓冲区
调⽤write时,数据会先写⼊发送缓冲区中;
如果发送的字节数太⻓,会被拆分成多个TCP的数据包发出;
如果发送的字节数太短,就会先在缓冲区⾥等待,等到缓冲区⻓度差不多了,或者其他合适的时机发送出去;
接收数据的时候,数据也是从⽹卡驱动程序到达内核的接收缓冲区;
然后应⽤程序可以调⽤read从接收缓冲区拿数据;
另⼀⽅⾯,TCP的⼀个连接,既有发送缓冲区,也有接收缓冲区,那么对于这⼀个连接,既可以读数据, 也可以写数据.这个概念叫做全双⼯

粘包问题

是 “面向字节流” 特性带来的典型现象 —— 接收方无法直接区分应用层发送的多个消息边界，导致多个消息被 “粘” 在一起接收，或一个消息被拆分成多个部分接收。

为什么会出现粘包？

发送方的缓冲与合并
发送方 TCP 为提高效率，会将应用层多次发送的小数据合并成一个大报文发送（Nagle 算法）。例如：应用层连续发送 "A"、"B"、"C" 三个小消息，TCP 可能将它们合并为一个报文发送，接收方一次收到 "ABC"，无法区分清原始的三个消息。
接收方的缓冲与拆分
接收方 TCP 会将收到的数据先放入缓冲区，再按需交付给应用层。如果缓冲区中的数据未被应用层及时读取，新到的数据会继续存入缓冲区，导致多个消息被 “粘” 在缓冲区中。
网络分段的不确定性
TCP 可能根据网络 MTU（最大传输单元）将大消息拆分成多个小报文传输，接收方可能分多次收到这些分段，导致一个完整消息被拆分接收。

粘包的表现形式

多包合一：多个消息被合并成一个报文接收。
一包拆分：一个消息被拆分成多个报文接收。
混合形式：部分消息合并，部分拆分。

如何解决粘包问题？

固定长度
约定每个消息的字节数固定（如 100 字节）。接收方每次读取固定长度的数据，不足时等待补全。
缺点：不适合长度多变的消息，可能浪费带宽。
分隔符
在消息末尾添加特殊分隔符（如 \r\n、| 等，需确保分隔符不会出现在消息内容中）。接收方通过分隔符拆分消息。
例：HTTP 协议用 \r\n 分隔请求头字段。
长度前缀
在消息头部添加固定长度的 “长度字段”，说明后续消息正文的字节数。接收方先读长度字段，再按长度读取对应字节数的正文。
例：二进制协议常用 4 字节整数表示消息长度

异常情况

进程终⽌:进程终⽌会释放⽂件描述符,仍然可以发送FIN.和正常关闭没有什么区别.
机器重启:和进程终⽌的情况相同.
机器掉电/⽹线断开:接收端认为连接还在,⼀旦接收端有写⼊操作,接收端发现连接已经不在了,就会进⾏reset.即使没有写⼊操作,TCP⾃⼰也内置了⼀个保活定时器,会定期询问对⽅是否还在.如果对⽅不在,也会把连接释放.

3.TCP/UDP对⽐

特性	TCP协议	UDP协议
连接性	面向连接（需三次握手建立连接，四次挥手关闭连接）	无连接（直接发送数据，无需建立/关闭连接）
可靠性	提供可靠传输（保证数据不丢失、不重复、按序到达）	不可靠传输（不保证数据到达，可能丢失、乱序）
数据边界	面向字节流（无消息边界，可能出现粘包）	面向报文（保留消息边界，不合并、不拆分）
拥塞控制与流量控制	有（通过滑动窗口、拥塞窗口等机制动态调整发送速率）	无（发送速率不受控制，可能导致网络拥塞）
首部开销	较大（固定首部20字节，可选扩展字段）	较小（固定首部8字节）
适用场景	对可靠性要求高的场景（文件传输、网页加载、邮件等）	对实时性要求高的场景（视频通话、游戏、广播等）

4.IP

主机:配有IP地址,但是不进⾏路由控制的设备;
路由器:即配有IP地址,⼜能进⾏路由控制;
节点:主机和路由器的统称;

协议头格式

4位版本号(version):指定IP协议的版本,对于IPv4来说,就是4
4位头部⻓度(headerlength):IP头部的⻓度是多少个32bit,也就是length*4的字节数.4bit表⽰最⼤的数字是15,因此IP头部最⼤⻓度是60字节
8位服务类型(TypeOfService):3位优先权字段(已经弃⽤),4位TOS字段,和1位保留字段(必须置为 0). 4位TOS分别表⽰:最⼩延时,最⼤吞吐量,最⾼可靠性,最⼩成本.这四者相互冲突,只能选择⼀个. 对于ssh/telnet这样的应⽤程序,最⼩延时⽐较重要;对于ftp这样的程序,最⼤吞吐量⽐较重要
16位总⻓度(totallength):IP数据报整体占多少个字节
16位标识(id):唯⼀的标识主机发送的报⽂.如果IP报⽂在数据链路层被分⽚了,那么每⼀个⽚⾥⾯的这个id都是相同的
3位标志字段:第⼀位保留(保留的意思是现在不⽤,但是还没想好说不定以后要⽤到).第⼆位置为1表⽰禁⽌分⽚,这时候如果报⽂⻓度超过MTU,IP模块就会丢弃报⽂.第三位表⽰"更多分⽚",如果分⽚了的话,最后⼀个分⽚置为1,其他是0.类似于⼀个结束标记.
13位分⽚偏移(framegamentoffset):是分⽚相对于原始IP报⽂开始处的偏移.其实就是在表⽰当前分⽚在原报⽂中处在哪个位置.实际偏移的字节数是这个值*8得到的.因此,除了最后⼀个报⽂之外,其他报⽂的⻓度必须是8的整数倍(否则报⽂就不连续了)
8位⽣存时间(TimeToLive,TTL):数据报到达⽬的地的最⼤报⽂跳数.⼀般是64.每次经过⼀个路由,TTL-=1,⼀直减到0还没到达,那么就丢弃了.这个字段主要是⽤来防⽌出现路由循环比特就业课
8位协议:表⽰上层协议的类型
16位头部校验和:使⽤CRC进⾏校验,来鉴别头部是否损坏
32位源地址和32位⽬标地址:表⽰发送端和接收端

地址管理

⽹络号:保证相互连接的两个⽹段具有不同的标识
主机号:同⼀⽹段内,主机之间具有相同的⽹络号,但是必须有不同的主机号

同一个局域网中不同设备网络号必须相同，主机号必须不同
相邻局域网中不同设备网络号必须不同，主机号无限制

IP不够用了怎么办

NAT（网络地址转换）

原理：在局域网（如家庭、企业内网）中使用私有 IPv4 地址（如192.168.x.x、10.x.x.x），仅通过 1-2 个公网 IPv4 地址接入互联网。NAT 设备（如家用路由器）负责在私有地址与公网地址之间转换，实现多设备共享一个公网 IP。
作用：极大减少对公网 IPv4 地址的消耗（一个公网 IP 可支持数十甚至上百台设备），是目前最广泛使用的短期解决方案。

CIDR（动态分配IP地址）