计算机网络

网络分层模型

OSI 七层模型

• 应用层：为计算机用户提供服务
• 表示层：数据处理(编解码、加密解密、压缩解压缩)
• 会话层：管理(建立、维护、重连)应用程序之间的会话
• 传输层：为两台主机进程之间的通信提供通用的数据传输服务
• 网络层：路由和寻址(决定数据在网络的游走路径)
• 数据链路层：帧编码和误差纠正控制
• 物理层：透明地传送比特流传输

TCP/IP 四层模型

• 应用层：提供两个终端设备上的应用程序之间的信息交换的服务，定义了信息交换的格式，消息交给下一次传输层来传输。应用层交互的数据单元称为 报文。
• 传输层：向两台终端设备之间的通信提供通用的数据传输服务。
• 网络层：负责为分组交换网的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。
• 网络接口层：数据链路层 + 物理层
  • 数据链路层：将网络层的 IP 数据报组装成帧，两个相邻节点间的链路上传送帧，每一帧包括数据和必要的控制信息(同步信息，地址信息，差错控制)
  • 物理层：实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。

分层原因

• 各层之间相互独立，不需要关心其它层的实现
• 提高整体灵活性，每一层使用最适合的技术，高内聚低耦合
• 大问题化小，功能分解

应用层

• HTTP：TCP，用于传输超文本和多媒体内容的协议，为了 Web 浏览器之间的通信设计的

• SMTP：TCP，用于发送电子邮件的协议，只发送，不是接收，从邮件服务器接收邮件需要使用 POP3 或 IMAP 协议

• POP3/IMAP：TCP，负责邮件的接收

• FTP：TCP，传输文件，可屏蔽操作系统和文件存储方式。不加密，不安全，使用 SFTP

• Telnet：远程登陆协议，TCP，所有数据明文，使用 SSH

• SSH：TCP，通过加密和认证机制实现安全的访问和文件传输等业务

• RTP：实时传输协议，UDP

• DNS：域名管理系统，UDP

传输层

• TCP：面向连接，可靠的数据传输服务

• UDP：无连接，尽最大努力的数据传输服务

应用需要传输的数据可能会非常大，如果直接传输就不好控制，因此当传输层的数据包大小超过 MSS（TCP 最大报文段长度），就要将数据包分块，这样即使中途有一个分块丢失或损坏了，只需要重新发送这一个分块，而不用重新发送整个数据包。在 TCP 协议中，我们把每个分块称为一个 TCP 段（TCP Segment）

网络层

• IP：网络协议，定义数据包的格式，对数据包进行路由和寻址，以便可以跨网络传输并到达正确的目的地。
• ARP：地址解析协议，解决网络层和链路层地址之间的转换问题，IP 转 MAC 地址
• ICMP：互联网控制报文协议，用于传输网络状态和错误消息的协议，用于网络诊断和故障排除，如 Ping
• NAT：网络地址转换协议，应用于内部网到外部网的地址转换过程。具体地说，在一个小的子网（局域网，LAN）内，各主机使用的是同一个 LAN 下的 IP 地址，但在该 LAN 以外，在广域网（WAN）中，需要一个统一的 IP 地址来标识该 LAN 在整个 Internet 上的位置。
• OSPF：开放式最短路径优先，内部网关协议，动态路由协议，基于链路状态算法，考虑链路的带宽，延迟选择最佳路径
• RIP：路由信息协议，内部网关协议，动态路由协议，基于距离向量算法，选择跳数最短的路径
• BGP：边界网关协议，路由选择域之间交换网络层可达性信息的路由选择协议

网络接口层

传输封装数据包

网络接口层的传输单位是帧（frame），IP 层的传输单位是包（packet），TCP 层的传输单位是段（segment），HTTP 的传输单位则是消息或报文（message）。但这些名词并没有什么本质的区分，可以统称为数据包。

输入 URL 到页面展示的过程

图解网络过程

过程	协议
浏览器查找域名的 IP 地址(DNS 查找过程：浏览器缓存，路由器缓存，DNS 缓存)	DNS：获取域名对应的 IP
浏览器向 Web 服务器发送一个 HTTP(TCP) 请求(cookies 随请求发送)	TCP：与服务器建立 TCP 连接
服务器处理请求(处理请求参数，cookies，生成 HTML 响应)	IP：建立 TCP 协议时，需要发送数据，发送数据在网络层使用 IP 协议
服务器返回一个 HTML 响应	OSPF：IP 数据包在路由器之间选择最佳路径
浏览器开始显示 HTML	ARP：IP 转 MAC 地址
	HTTP：TCP 建立完成，使用 HTTP 访问网页

1. 在浏览器中输入指定网页的 URL。
2. 浏览器通过 DNS 协议，获取域名对应的 IP 地址，本地 DNS 服务器 -> 根 DNS 服务器 -> 顶级域名服务器 -> 权威域名服务器 -> 保存到本地 DNS 服务器(浏览器缓存，操作系统缓存)。
3. 浏览器根据 IP 地址和端口号，向目标服务器发起一个 TCP 连接请求，三次握手，超过 MSS 长度分段。
4. 浏览器在 TCP 连接上，向服务器发送一个 HTTP 请求报文，请求获取网页的内容。
5. 服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
6. 浏览器收到 HTTP 响应报文后，解析响应体中的 HTML 代码，渲染网页的结构和样式，同时根据 HTML 中的其他资源的 URL（如图片、CSS、JS 等），再次发起 HTTP 请求，获取这些资源的内容，直到网页完全加载显示。
7. 浏览器在不需要和服务器通信时，可以主动关闭 TCP 连接，或者等待服务器的关闭请求。

URL

协议 + 域名 + 端口 + 资源路径 + 参数

HTTP

HTTP 状态码

状态码	类别	原因
1XX	Informational(信息性状态码)	接收的请求正在处理
2XX	Success(成功状态码)	请求处理完毕
3XX	Redirection(重定向状态码)	需要进行附加操作以完成请求
4XX	Client Error(客户端错误状态码)	服务器无法处理请求
5XX	Server Error(服务端错误状态码)	服务器处理请求错误

• 200 OK：请求被成功处理。比如我们发送一个查询用户数据的 HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。

• 201 Created：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。

• 202 Accepted：服务端已经接收到了请求，但是还未处理。

• 204 No Content：服务端已经成功处理了请求，但是没有返回任何内容。

• 301 Moved Permanently：资源被永久重定向了。比如你的网站的网址更换了。

• 302 Found：资源被临时重定向了。比如你的网站的某些资源被暂时转移到另外一个网址。

• 400 Bad Request：发送的 HTTP 请求存在问题。比如请求参数不合法、请求方法错误。

• 401 Unauthorized：未认证却请求需要认证之后才能访问的资源。

• 403 Forbidden：直接拒绝 HTTP 请求，不处理。一般用来针对非法请求。

• 404 Not Found：你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。

• 409 Conflict：表示请求的资源与服务端当前的状态存在冲突，请求无法被处理。

• 500 Internal Server Error：服务端出问题了（通常是服务端出 Bug 了）。比如你服务端处理请求的时候突然抛出异常，但是异常并未在服务端被正确处理。

• 502 Bad Gateway：我们的网关将请求转发到服务端，但是服务端返回的却是一个错误的响应。

HTTP 常见字段

• Host: www.A.com
• Content-Length：服务器回应的数据长度
• Connection：Keep-Alive：长连接
• Content-Type：服务端发送的数据格式
• Accept：客户端接收的数据格式
• Content-Encoding：数据压缩格式

HTTP 缓存

强制缓存

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

• Cache-Control，是一个相对时间；
• Expires，是一个绝对时间；

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control 的优先级高于 Expires 。

• 当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
• 浏览器再次请求访问服务器中的该资源时，会先 通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
• 服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

协商缓存

协商缓存可以基于两种头部来实现：

• 请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现
• 请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段

第一种实现方式是基于时间实现的，第二种实现方式是基于一个唯一标识实现的，相对来说后者可以更加准确地判断文件内容是否被修改，避免由于时间篡改导致的不可靠问题。

HTTP vs HTTPS

• 端口号：HTTP 默认 80，HTTPS 默认 443
• URL 前缀：http:// 和 https://
• 安全性和资源消耗：HTTP 协议运行在 TCP 上，传输明文，客户端和服务端都无法验证对方身份。HTTPS 运行在 SSL/TLS 之上，SSL/TLS 运行在 TCP 上，传输内容经过加密，使用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密，HTTP 没有 HTTPS 安全，HTTPS 资源耗费高
• SEO：搜索引擎青睐使用 HTTPS 协议的网站

混合加密

非对称加密：一个公钥，一个私钥，通信时，私钥由解密者保存，公钥由任何一个想与解密者通信的发送者(加密者)所知，公钥只能加锁，私钥来解锁

对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。

HTTPS 采用的是 对称加密 和 非对称加密 结合的「混合加密」方式：

• 在通信建立前采用 非对称加密 的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用 对称加密 的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

• 对称加密 只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
• 非对称加密 使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

摘要算法 + 数字签名

为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，然后同内容一起传输给对方。

对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。

那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。

数字证书

• 可以通过哈希算法来保证消息的完整性；
• 可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；
• 数字证书用来保证服务器公钥的身份，解决冒充的风险。

HTTPS 连接过程

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

HTTP/1.0 vs HTTP/1.1

• 连接方式：1.0 短连接，1.1 支持长连接，一次 TCP 连接后不会关闭
• 状态响应码：加入大量响应码
• 缓存机制：1.0 使用 Header 的 If-Modified-Since, Expires 来做为缓存判断的标准，HTTP/1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match
• 带宽：1.1 引入 range 头域，支持只请求资源的某个部分
• Host 头处理：允许同一 ip 地址托管多个域名，支持虚拟主机的功能

HTTP/1.1 vs HTTP/2.0

• 多路复用：2.0 同一连接可以传输多个请求和响应，互补干扰，1.0 为串行
• 二进制帧：2.0 使用二进制帧进行数据传输，1.0 使用文本格式的报文
• 头部压缩：1.0 支持 Body 压缩，Header 不支持压缩，2.0 都支持
• 服务器推送：2.0 客户端请求一个资源时，其他相关资源一并推送给客户端

HTTP 时不保存状态协议，如何保存用户状态

HTTP 时无状态协议，使用 Session 机制，通过服务器记录用户的状态，内存/数据库，在 Cookie 中附加一个 Session ID

Cookie 被禁用：把 Session ID 附加在 URL 后面

URI vs URL

URI：统一资源标志符，唯一标识一个资源

URL：统一资源定位符，具体的 URI，不仅标识，还指明如何 locate 这个资源

GET vs POST

• 语义：GET 通常获取和查询资源，POST 通常创建和修改资源
• 幂等：GET 时幂等的，多次重复执行不改变资源的状态，POST 不幂等，每次执行可能产生不同结果
• 格式：GET 请求参数一般放 URL，长度受限；POST 请求体 body 里面，multipart/form-data、application/json
• 缓存：GET 可以被缓存，提高性能
• 安全性：HTTP 都不安全，明文，GET 参数放 URL 更不安全

WebSocket

客户端和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

应用场景：

• 视频弹幕
• 实时消息推送
• 实时游戏对战
• 多用户协同编辑
• 社交聊天

WebSocket vs HTTP

• WebSocket 是双向实时通信协议，HTTP 是一种单向通信协议，服务器无法主动通知客户端
• WebSocket 使用 ws:// 或 wss://
• WebSocket 支持拓展，实现自定义的子协议，如支持压缩、加密
• WebSocket 通信数据格式比较轻量，用于协议控制的数据包头部相对较小，网络开销小，而 HTTP 通信每次都要携带完整的头部，网络开销较大（HTTP/2.0 使用二进制帧进行数据传输，还支持头部压缩，减少了网络开销）。

工作流程

1. 客户端发送一个 HTTP 请求，请求头中包含 Upgrade: websocket 和 Sec-WebSocket-Key 等字段，表示要求升级协议为 WebSocket；
2. 服务器收到这个请求后，会进行升级协议的操作，如果支持 WebSocket，它将回复一个 HTTP 101 状态码，响应头中包含 ，Connection: Upgrade 和 Sec-WebSocket-Accept: xxx 等字段、表示成功升级到 WebSocket 协议。
3. 客户端和服务器之间建立了一个 WebSocket 连接，可以进行双向的数据传输。数据以帧（frames）的形式进行传送，WebSocket 的每条消息可能会被切分成多个数据帧（最小单位）。发送端会将消息切割成多个帧发送给接收端，接收端接收消息帧，并将关联的帧重新组装成完整的消息。
4. 客户端或服务器可以主动发送一个关闭帧，表示要断开连接。另一方收到后，也会回复一个关闭帧，然后双方关闭 TCP 连接。

另外，建立 WebSocket 连接之后，通过心跳机制来保持 WebSocket 连接的稳定性和活跃性。

SSE 和 WebSocket 区别

SSE 与 WebSocket 作用相似，都可以建立服务端与浏览器之间的通信，实现服务端向客户端推送消息，但还是有些许不同：

• SSE 是基于 HTTP 协议的，它们不需要特殊的协议或服务器实现即可工作；WebSocket 需单独服务器来处理协议。
• SSE 单向通信，只能由服务端向客户端单向通信；WebSocket 全双工通信，即通信的双方可以同时发送和接受信息。
• SSE 实现简单开发成本低，无需引入其他组件；WebSocket 传输数据需做二次解析，开发门槛高一些。
• SSE 默认支持断线重连；WebSocket 则需要自己实现。
• SSE 只能传送文本消息，二进制数据需要经过编码后传送；WebSocket 默认支持传送二进制数据。

PING

• ICMP Echo Request（请求报文）信息：序列号、TTL（Time to Live）值。

• 目标主机的域名或 IP 地址：输出结果的第一行。

• 往返时间（RTT，Round-Trip Time）：从发送 ICMP Echo Request（请求报文）到接收到 ICMP Echo Reply（响应报文）的总时间，用来衡量网络连接的延迟。

• 统计结果（Statistics）：包括发送的 ICMP 请求数据包数量、接收到的 ICMP 响应数据包数量、丢包率、往返时间（RTT）的最小、平均、最大和标准偏差值。

工作原理

PING 基于网络层的 ICMP，通过在网络上发送和接收 ICMP 报文实现。

ICMP 报文中包含了类型字段，用于标识 ICMP 报文类型：

• 查询报文类型：向主机发送请求并期望得到响应
• 差错报文类型：向源主机发送错误信息，用于报告网络中的错误信息。

PING 用到的 ICMP Echo Request（类型为 8 ） 和 ICMP Echo Reply（类型为 0） 属于查询报文类型 。

• PING 命令会向目标主机发送 ICMP Echo Request。
• 如果两个主机的连通性正常，目标主机会返回一个对应的 ICMP Echo Reply。

DNS

域名管理系统：实现域名和 IP 的映射

• 浏览器 DNS 缓存，操作系统 DNS 缓存，路由器 DNS 缓存。
• DNS 是应用层协议，它可以在 UDP 或 TCP 协议之上运行，端口为 53 。
• 根 DNS 服务器，顶级域 DNS 服务器，权威 DNS 服务器，本地 DNS 服务器

DNS 解析过程

反复解析(迭代解析):

访问 netlab.csse.szu.edu.cn

本地域名服务器 -> 根域名服务器 edu.cn -> 本地 -> szu 域名服务器 szu.edu.cn -> 本地 -> csse 域名服务器 csse.szu.edu.cn -> 本地

递归解析：

本地域名服务器 -> 根域名服务器 edu.cn -> szu 域名服务器 szu.edu.cn -> csse 域名服务器 csse.szu.edu.cn -> ... -> 本地

DNS 劫持

​ DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。

TCP 和 UDP

TCP

区别

1. 是否面向连接：UDP 在传送数据前不需要向建立连接，而 TCP 提供面向连接的服务，在传送数据之前需要向建立连接，结束后释放连接
2. 是否可靠传输：远程主机在收到 UDP 报文后，不需要给出确认，不保证数据不丢失，不保证是否顺序到达。TCP 提供可靠的传输服务，在传输数据之前，会有三次握手建立连接，在数据传输时，有确认、窗口、重传、拥塞控制机制。TCP 传输能无差错、不丢失、不重复、并且按序到达。
3. 是否有状态：TCP 有状态，记录消息是否发送，接收等，TCP 维护复杂的连接状态表，UDP 无状态
4. 传输效率：UDP 更快
5. 传输形式：TCP 字节流，UDP 报文
6. 首部开销：TCP 20 ~ 60 字节，UDP 8 字节
7. 是否提供广播或多播服务：TCP 只支持点对点通信，UDP 支持一对一，多对多。

应用场景

UDP：即时通信，如语音、视频、直播 (DHCP：动态主机配置 ip 协议)

TCP：传输准确性高，文件传输，邮件，远程登陆

https://cloud.tencent.com/developer/article/2157079

TCP 三次握手

三次握手流程

• 一次握手：client 发送带有 SYN(SEQ = x)标志的数据包给 Server，client 进入 SYN_SEND 状态，等待服务器的确认
• 二次握手：Server 发送带有 SYN+ACK(SEQ = y, ACK = x+1)标志的数据包给 Client，然后服务器进入 SYN_RECV 状态
• 三次握手：Client 发送带有 ACK(ACK = y+1)标志的数据包给 Client，客户端和服务器进入 ESTABLISHED 状态

为什么需要三次握手？

确保双方的收发都是正常的

• 第一次握手：Client 无法确认；Server 确认了对方发送正常，自己接收正常
• 第二次握手：Client 确认了自己收发正常，Server 确认了对方发送正常，自己接收正常
• 第三次握手：Client，Server 都确认双方收发正常

两次握手/四次握手

• 两次握手不安全：Server 无法确认客户端的接收是否正常/服务端的发送是否正常
• 四次没必要

三次握手可以携带数据吗？

​ 第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。假设第一次可以携带数据，如果有人恶意攻击服务器，每次都在第一次握手中的 SYN 报文放入大量数据，重复发送大量 SYN 报文，此时服务器会花费大量内存空间来缓冲这些报文，服务器就更容易被攻击了

三次握手失败，服务端会如何处理?

• 服务端没有收到 SYN，则什么都不做；
• 服务端回复了 SYN+ACK 后，长时间没有收到 ACK 响应，则超时后就会发送 RST 重置连接报文，释放资源

ISN 代表什么？意义何在？ISN 是固定不变的吗？ISN 为何要动态随机

​ ISN 全称是 Initial Sequence Number，是 TCP 发送方的字节数据编号的原点，告诉对方我要开始发送数据的初始化序列号。ISN 如果是固定的，攻击者很容易猜出后序的确认号，为了安全起见，避免被第三方猜到从而发送伪造的 RST 报文，因此 ISN 是动态生成的

TCP 四次挥手

四次挥手流程

• 第一次挥手：Client 发送一个 FIN(SEQ = x)标志的数据包给 Server，用来关闭 Client 到服务器的数据传送。然后 Client 进入 FIN-WAIT-1 状态
• 第二次挥手：Server 收到这个 FIN(SEQ = x)标志的数据包，发送 ACK(ACK = x+1)标志的数据包给 Client，然后 Server 进入 CLOSE-WAIT 状态，Client 进入 FIN-WAIT-2 状态
• 第三次挥手：Server 发送一个 FIN(SEQ = y)标志的数据包给 Client，请求关闭连接，Server 进入 LAST-ACK 状态
• 第四次挥手：Client 发送 ACK(ACK = y+1)标志的数据包给 Server，然后 Client 进入 TIME-WAIT 状态，Server 在收到 ACK(ACK = y+1)的数据包后进入 CLOSE 状态，如果 Client 等待 2MSL 后没收到回复，则 Server 正常关闭，Client 也可以关闭连接了

为什么四次挥手

​ 其实在 TCP 握手的时候，接收端将 SYN 包和 ACK 确认包合并到一个包中发送的，所以减少了一次包的发送。对于四次挥手，由于 TCP 是全双工通信，主动关闭方发送 FIN 请求不代表完全断开连接，只能表示 主动关闭方不再发送数据了。而 接收方可能还要发送数据，就不能立即关闭服务器端到客户端的数据通道，所以就不能将服务端的 FIN 包和对客户端的 ACK 包合并发送，只能先确认 ACK，等服务器无需发送数据时在发送 FIN 包，所以四次挥手时需要四次数据包的交互

举个例子：A 和 B 打电话，通话即将结束后。

1. 第一次挥手：A 说“我没啥要说的了”
2. 第二次挥手：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
3. 第三次挥手：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
4. 第四次挥手：A 回答“知道了”，这样通话才算结束。

为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？

​ 因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。

如果第二次挥手时服务器的-ack-没有送达客户端-会怎样

​ 客户端没有收到 ACK 确认，会重新发送 FIN 请求。

为什么第四次挥手客户端需要等待 2MSL（报文段最长寿命）时间后才进入 CLOSED 状态？

​ 第四次挥手时，客户端发送给服务器的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。

​ 客户端发送 ACK 后需要留出 2MSL 时间（ACK 到达服务器器+服务器发送 FIN 重传包，一来一回）等待确认服务器端缺失收到了 ACK 包。也就是说客户端如果等待 2MSL 时间也没收到服务器端重传的 FIN 包，则就可以确认服务器已经收到客户端发送的 ACK 包

一台主机上出现大量的 TIME_WAIT 是什么原因？应该如何处理？

​ TIME_WAIT 是主动关闭方出现的，一台主机出现大量的 TIME_WAIT 证明这台主机上发起大量的主动关闭连接。常见于一些爬虫服务器。这时候我们应该调整 TIME_WAIT 的等待时间，或者开启套接字地址重用选项

一台主机上出现大量的 CLOSE_WAIT 是什么原因？应该如何处理？

​ CLOSE_WAIT 是被动关闭方收到 FIN 请求进行回复之后的状态，等待上层程序进一步处理，若出现大量 CLOSE_WAIT，有可能是被动关闭方主机程序中忘了最后一步断开连接后调用 close 释放资源。这是一个 BUG.，只需要加上对应的 close 即可解决问题

TCP 传输可靠性保障

TCP 如何保证传输可靠性？

• 基于数据块传输：应用数据被分割成 TCP 认为最适合发送的数据块，再传输给网络层，数据块被称为报文段或段。
• 对失序数据包重新排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。
• 校验和 : TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
• 重传机制 : 在数据包丢失或延迟的情况下，重新发送数据包，直到收到对方的确认应答（ACK）。TCP 重传机制主要有：基于计时器的重传（也就是超时重传）、快速重传（基于接收端的反馈信息来引发重传）、SACK（在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了）、D-SACK（重复 SACK，在 SACK 的基础上，额外携带信息，告知发送方有哪些数据包自己重复接收了）。关于重传机制的详细介绍，可以查看 详解 TCP 超时与重传机制
• 这篇文章。
• 流量控制 : TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议（TCP 利用滑动窗口实现流量控制）。
• 拥塞控制 : 当网络拥塞时，减少数据的发送。TCP 在发送数据的时候，需要考虑两个因素：一是接收方的接收能力，二是网络的拥塞程度。接收方的接收能力由滑动窗口表示，表示接收方还有多少缓冲区可以用来接收数据。网络的拥塞程度由拥塞窗口表示，它是发送方根据网络状况自己维护的一个值，表示发送方认为可以在网络中传输的数据量。发送方发送数据的大小是滑动窗口和拥塞窗口的最小值，这样可以保证发送方既不会超过接收方的接收能力，也不会造成网络的过度拥塞。

TCP 流量控制

利用滑动窗口实现流量控制，为了控制发送方的发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率，为 0 时发送方不能发送数据

为什么需要流量控制? 这是因为双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来。如果接收方处理不过来的话，就只能把处理不过来的数据存在 接收缓冲区(Receiving Buffers) 里（失序的数据包也会被存放在缓存区里）。如果缓存区满了发送方还在狂发数据的话，接收方只能把收到的数据包丢掉。出现丢包问题的同时又疯狂浪费着珍贵的网络资源。因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

TCP 发送窗口可以划分成四个部分：

1. 已经发送并且确认的 TCP 段（已经发送并确认）；
2. 已经发送但是没有确认的 TCP 段（已经发送未确认）；
3. 未发送但是接收方准备接收的 TCP 段（可以发送）；
4. 未发送并且接收方也并未准备接受的 TCP 段（不可发送）。

• SND.WND：发送窗口。
• SND.UNA：Send Unacknowledged 指针，指向发送窗口的第一个字节。
• SND.NXT：Send Next 指针，指向可用窗口的第一个字节。

可用窗口大小 = SND.UNA + SND.WND - SND.NXT 。

TCP 接收窗口可以划分成三个部分：

1. 已经接收并且已经确认的 TCP 段（已经接收并确认）；
2. 等待接收且允许发送方发送 TCP 段（可以接收未确认）；
3. 不可接收且不允许发送方发送 TCP 段（不可接收）。

接收窗口的大小是根据接收端处理数据的速度动态调整的。 如果接收端读取数据快，接收窗口可能会扩大。 否则，它可能会缩小。

另外，这里的滑动窗口大小只是为了演示使用，实际窗口大小通常会远远大于这个值。

拥塞控制

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即 慢开始、 拥塞避免、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1.
• 快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

ARQ

自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认信息（Acknowledgements，就是我们常说的 ACK），它通常会重新发送，直到收到确认或者重试超过一定的次数。

ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

停止等待协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

• 无差错情况： 发送方发送分组，接收方在规定时间内收到，并且回复确认，发送发再次发送。
• 出现差错： 重传前面发送的分组，另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。
• 确认丢失： 当 A 发送 M1 消息，B 收到后，B 向 A 发送了一个 M1 确认消息，但却在传输过程中丢失。而 A 并不知道，在超时计时过后，A 重传 M1 消息，B 再次收到该消息后采取以下两点措施：1. 丢弃这个重复的 M1 消息，不向上层交付。 2. 向 A 发送确认消息。（不会认为已经发送过了，就不再发送。A 能重传，就证明 B 的确认消息丢失）。
• 确认迟到： 确认消息在传输过程中迟到。A 发送 M1 消息，B 收到并发送确认。在超时时间内没有收到确认消息，A 重传 M1 消息，B 仍然收到并继续发送确认消息（B 收到了 2 份 M1）。此时 A 收到了 B 第二次发送的确认消息。接着发送其他数据。过了一会，A 收到了 B 第一次发送的对 M1 的确认消息（A 也收到了 2 份确认消息）。处理如下：1. A 收到重复的确认后，直接丢弃。2. B 收到重复的 M1 后，也直接丢弃重复的 M1。

IP

IP 是 TCP/IP 协议中最重要的协议，属于网络层的协议，作用是定义数据包的格式、对数据包进行路由和寻址，以便可以跨网传播并到达正确的目的地

IP 协议会将传输层的报文作为数据部分，再加上 IP 包头组装成 IP 报文，如果 IP 报文大小超过 MTU（以太网中一般为 1500 字节）就会 再次进行分片，得到一个即将发送到网络的 IP 报文。

IP 地址 及 如何工作

当网络设备发送 IP 数据包时，包含了源 IP 地址和目的 IP 地址

什么是 IP 地址过滤？

IP 地址过滤（IP Address Filtering） 简单来说就是限制或阻止特定 IP 地址或 IP 地址范围的访问。例如，你有一个图片服务突然被某一个 IP 地址攻击，那我们就可以禁止这个 IP 地址访问图片服务。

IP 地址过滤是一种简单的网络安全措施，实际应用中一般会结合其他网络安全措施，如认证、授权、加密等一起使用。单独使用 IP 地址过滤并不能完全保证网络的安全。

NAT 作用

NAT（Network Address Translation，网络地址转换） 主要用于在不同网络之间转换 IP 地址。它允许将私有 IP 地址（如在局域网中使用的 IP 地址）映射为公有 IP 地址（在互联网中使用的 IP 地址）或者反向映射，从而实现局域网内的多个设备通过单一公有 IP 地址访问互联网。

NAT 不光可以缓解 IPv4 地址资源短缺的问题，还可以隐藏内部网络的实际拓扑结构，使得外部网络无法直接访问内部网络中的设备，从而提高了内部网络的安全性。

NAT 协议在 LAN 以外，标识一个内部主机时，使用的是端口号，因为 IP 地址都是相同的。

ARP

一切网络设备都由 MAC 地址唯一标识。ARP 协议是一个 广播问询，单播响应 协议。

ARP 协议，全称 地址解析协议（Address Resolution Protocol），它解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址 ，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。