计算机网络复习总结

计算机网络复习总结

基础篇

为什么有Tcp/ip网络模型

• 对于同一台设备上的进程间通信，有很多种方式，比如有管道、消息队列、共享内存、信号等方式，而对于不同设备上的进程间通信，就需要网络通信，而设备是多样性的，所以要兼容多种多样的设备，就协商出了一套通用的网络协议
• 这个网络协议是分层的，每一层都有各自的作用和职责

tcp/ip模型有哪几层？

• TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层
• 表示层 会话层 数据链路层 物理层
• 网络接口层的传输单位是帧（frame），IP 层的传输单位是包（packet），TCP 层的传输单位是段（segment），HTTP 的传输单位则是消息或报文（message）。但这些名词并没有什么本质的区分，可以统称为数据包。

键入网址到网页显示 发生了什么？

• 孤单小弟 —— HTTP ： 浏览器做的第一步工作是解析 URL 生成发送给 Web 服务器的请求信息

  • 图中的长长的 URL 实际上是请求服务器里的文件资源
  • 当没有路径名时，就代表访问根目录下事先设置的默认文件
  • 生产 HTTP 请求信息

• 真实地址查询 —— DNS : 通过浏览器解析 URL 并生成 HTTP 消息后，需要委托操作系统将消息发送给 Web 服务器

  • 发送之前，还有一项工作需要完成，那就是查询服务器域名对应的 IP 地址
  • 有一种服务器就专门保存了 Web 服务器域名与 IP 的对应关系，它就是 DNS 服务器
  • 域名都是用句点来分隔的，越靠右的位置表示其层级越高
  • 域名的层级关系类似一个树状结构：
    • 根 DNS 服务器（.）
    • 顶级域 DNS 服务器（.com）
    • 权威 DNS 服务器（server.com）
  • 浏览器会先看自身有没有对这个域名的缓存，如果有，就直接返回，如果没有，就去问操作系统，操作系统也会去看自己的缓存，如果有，就直接返回，如果没有，再去 hosts 文件看，也没有，才会去问「本地 DNS 服务器

• 指南好帮手 —— 协议栈 ： HTTP 的传输工作交给操作系统中的协议栈

  • 应用程序（浏览器）通过调用 Socket 库，来委托协议栈工作。协议栈的上半部分有两块，分别是负责收发数据的 TCP 和 UDP 协议，这两个传输协议会接受应用层的委托执行收发数据的操作。
  • 协议栈的下面一半是用 IP 协议控制网络包收发操作，在互联网上传数据时，数据会被切分成一块块的网络包，而将网络包发送给对方的操作就是由 IP 负责的
  • IP 中还包括 ICMP 协议和 ARP 协议。
    • ICMP 用于告知网络包传送过程中产生的错误以及各种控制信息。
    • ARP 用于根据 IP 地址查询相应的以太网 MAC 地址

• 可靠传输 —— TCP ： HTTP 是基于 TCP 协议传输的；

  • tcp头部报文格式：
    • 源端口号 16位 ：源端口号和目标端口号是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用
    • 目的端口号 16位
    • 序号 32位：这个是为了解决包乱序的问题
    • 确认序列 32位 ： 目的是确认发出去对方是否有收到。如果没有收到就应该重新发送，直到送达，这个是为了解决不丢包的问题
    • 状态位 SYN ACK RST FIN
    • 窗口大小。TCP 要做流量控制
    • TCP还会做拥塞控制 控制自己，也即控制发送的速度。不能改变世界，就改变自己
    • 另：三次握手 目的：**保证双方都有发送和接收的能力 ** 5条
      • 一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
      • 然后客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。
      • 服务端收到发起的连接，返回 SYN，并且 ACK 客户端的 SYN，之后处于 SYN-RCVD 状态。
      • 客户端收到服务端发送的 SYN 和 ACK 之后，发送对 SYN 确认的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了。
      • 服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了
    • 查看tcp的连接状态 netstat -napt
    • tcp分割数据 ： 超过了 MSS 的长度
      • MTU：一个网络包的最大长度，以太网中一般为 1500 字节。
      • MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度

• 远程定位 —— IP ： TCP 模块在执行连接、收发、断开等各阶段操作时，都需要委托 IP 模块将数据封装成网络包发送给通信对象

  • 在 IP 协议里面需要有源地址 IP 和 目标地址 IP
  • 客户端有多个网卡，就会有多个 IP 地址，那 IP 头部的源地址应该选择哪个 IP 呢？
    • 根据路由表规则，来判断哪一个网卡作为源地址 IP route -n
    • 和第一条目的子网掩码（Genmask）进行 与运算 与 destination 比较
    • 其他所有条目都无法匹配 匹配默认网关
  • 加上了 IP 头部的数据包表示 ：“有 IP 大佬给我指路了，感谢 IP 层给我加上了 IP 包头，让我有了远程定位的能力

• 两点传输 —— MAC ： 生成了 IP 头部之后，接下来网络包还需要在 IP 头部的前面加上 MAC 头部

  • 在 MAC 包头里需要发送方 MAC 地址和接收方目标 MAC 地址，用于两点之间的传输
  • MAC 发送方和接收方如何确认?
    • 发送方的 MAC 地址获取就比较简单了，MAC 地址是在网卡生产时写入到 ROM 里的，只要将这个值读取出来写入到 MAC 头部就可以了
    • 接收方 按如何获取对方的 MAC 地址呢？需要 ARP 协议帮我们找到路由器的 MAC 地址
      • ARP 协议会在以太网中以广播的形式，对以太网所有的设备喊出：“这个 IP 地址是谁的？请把你的 MAC 地址告诉我”
      • 后续操作系统会把本次查询结果放到一块叫做 ARP 缓存的内存空间留着以后用，不过缓存的时间就几分钟
      • 先查询 ARP 缓存

• 出口 —— 网卡 ： 网络包只是存放在内存中的一串二进制数字信息，没有办法直接发送给对方。因此，我们需要将数字信息转换为电信号，才能在网线上传输，也就是说，这才是真正的数据发送过程

  • 负责执行这一操作的是网卡，要控制网卡还需要靠网卡驱动程序
  • 网卡驱动获取网络包之后，会将其复制到网卡内的缓存区中，接着会在其开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列
    • 起始帧分界符是一个用来表示包起始位置的标记
    • 末尾的 FCS（帧校验序列）用来检查包传输过程是否有损坏

• 送别者 —— 交换机 ： 交换机的设计是将网络包原样转发到目的地。交换机工作在 MAC 层，也称为二层网络设备

  • 相对地，交换机的端口不核对接收方 MAC 地址，而是直接接收所有的包并存放到缓冲区中。因此，和网卡不同，交换机的端口不具有 MAC 地址

  • 根据MAC地址表 ， 交换机根据 MAC 地址表查找 MAC 地址，然后将信号发送到相应的端口

  • 如果接收方 MAC 地址是一个广播地址，那么交换机会将包发送到除源端口之外的所有端口。

    以下两个属于广播地址：

    • MAC 地址中的 FF:FF:FF:FF:FF:FF
    • IP 地址中的 255.255.255.255

  • 数据包通过交换机转发抵达了路由器

• 出境大门 —— 路由器 ：

  • 因为路由器是基于 IP 设计的，俗称三层网络设备，路由器的各个端口都具有 MAC 地址和 IP 地址；
  • 而交换机是基于以太网设计的，俗称二层网络设备，交换机的端口不具有 MAC 地址。
  • 路由器的端口都具有 MAC 地址，只接收与自身地址匹配的包，遇到不匹配的包则直接丢弃
  • MAC 头部的作用就是将包送达路由器
  • 在网络包传输的过程中，源 IP 和目标 IP 始终是不会变的，一直变化的是 MAC 地址，因为需要 MAC 地址在以太网内进行两个设备之间的包传输

Linux系统如何收发网络包？

• 电脑与电脑之间通常都是通话网卡、交换机、路由器等网络设备连接到一起，那由于网络设备的异构性，国际标准化组织定义了一个七层的 OSI 网络模型，但是这个模型由于比较复杂，实际应用中并没有采用，而是采用了更为简化的 TCP/IP 模型，Linux 网络协议栈就是按照了该模型来实现的。
• TCP/IP 模型主要分为应用层、传输层、网络层、网络接口层四层，每一层负责的职责都不同，这也是 Linux 网络协议栈主要构成部分。
• 当应用程序通过 Socket 接口发送数据包，数据包会被网络协议栈从上到下进行逐层处理后，才会被送到网卡队列中，随后由网卡将网络包发送出去。
• 而在接收网络包时，同样也要先经过网络协议栈从下到上的逐层处理，最后才会被送到应用程序

http篇

http常见面试题

• HTTP 是什么？HyperText Transfer Protocol 超文本传输协议

  • HTTP 是一个在计算机世界里专门在**「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」**

• http常见的状态码？

  • 1xx 类状态码属于提示信息，是协议处理中的一种中间状态 用到的比较少
  • 2xx 类状态码表示服务器成功处理了客户端的请求 最愿意看到的状态
  • 3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向
  • 4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义
  • 5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码

• http常见的字段？

  • Host 字段 ：指定服务器的域名
  • Content-Length 字段： 表明本次回应的数据长度
  • Connection 字段：常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用
  • Content-Type 字段：用于服务器回应时，告诉客户端，本次数据是什么格式
  • Content-Encoding 字段：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

• get与post的区别？

  • GET 的语义是从服务器获取指定的资源
  • POST 的语义是根据请求负荷（报文body）对指定的资源做出处理

• GET 和 POST 方法都是安全和幂等的吗

  • 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源
  • 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的
  • GET 方法就是安全且幂等
  • POST 不安全 不幂等 （新增或提交数据）

• http缓存有哪些实现方式？

  • 具有重复性的 HTTP 请求，比如每次请求得到的数据都一样，把这对「请求-响应」的数据都缓存在本地，避免发送 HTTP 请求的方法就是通过缓存技术
  • HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存
  • 强制缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边
  • 协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。
  • 只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求

http 1.1 的优点？ 3个 缺点 ？ 3个

• HTTP 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」
  • 简单 ：基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解
  • 灵活和易于扩展：HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充
  • 应用广泛和跨平台：从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性
• 「无状态、明文传输」，同时还有一大缺点「不安全」 双刃剑
  • 无状态双刃剑：
    • 无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务
    • 无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦
    • 对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术
  • 明文传输双刃剑
    • 方便阅读
    • 信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取
  • 不安全
    • 可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致

http 1.1 性能怎么样？

• HTTP/1.1 的性能一般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能
• http1.1 采用了长连接的方式 ，使得管道（pipeline）网络传输成为了可能，但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应，所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞

HTTP 与 HTTPS 有哪些区别？ 4条

1. HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
2. HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
3. HTTP 的端口号是 80，HTTPS 的端口号是 443。
4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 解决了 HTTP 的哪些问题？如何解决？ 3个

• HTTP 由于是明文传输，所以安全上存在以下三个风险：

  1. 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
  2. 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
  3. 冒充风险，比如冒充淘宝网站，用户钱容易没

• 加入了 SSL/TLS 协议 ：信息加密 校验机制 身份证书

• 如何解决？

  • 混合加密的方式实现信息的机密性，解决了窃听的风险

  • 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险

  • 将服务器公钥放入到数字证书中，解决了冒充的风险

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

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

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

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

HTTPS 是如何建立连接的？其间交互了什么？

SSL/TLS 协议基本流程：

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

前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。

SSL/TLS 的「握手阶段」涉及四次通信

HTTP/1.1 相比 HTTP/1.0 提高了什么性能

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

• 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
• 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

• 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
• 没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应

HTTP/2 做了什么优化？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的

1. 头部压缩 ：协议会帮你消除重复的部分。

2.二进制格式 ：HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了**二进制格式 ** 增加了数据传输的效率

3.数据流 ：不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ）

4.多路复用：HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应

5. 服务器推送 ：HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

• HTTP/2 有什么缺陷？ 队头阻塞
  • HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题

HTTP/3 做了哪些优化？

• HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
• 大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输

HTTP/1.1如何优化？

• 三种优化思路来优化 HTTP/1.1 协议：
  • 尽量避免发送 HTTP 请求；
  • 在需要发送 HTTP 请求时，考虑如何减少请求次数；
  • 减少服务器的 HTTP 响应的数据大小**；

https如何优化

• 硬件优化的方向 协议优化的方向 证书优化的方向

tcp篇

TCP 三次握手与四次挥手面试题

• 为什么需要 TCP 协议？ TCP 工作在哪一层？

  IP 层是「不可靠」的，它不保证网络包的交付、不保证网络包的按序交付、也不保证网络包中的数据的完整性

• 因为 TCP 是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的

• 什么是tcp？ TCP 是面向连接的、可靠的、基于字节流的传输层通信协议

  • 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
  • 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
  • 字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。

• 什么是 TCP 连接？ 简单来说就是用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接

  • Socket：由 IP 地址和端口号组成
  • 序列号：用来解决乱序问题等
  • 窗口大小：用来做流量控制

• 如何唯一确定一个 TCP 连接呢？

• TCP 四元组可以唯一的确定一个连接，四元组包括如下：

  • 源地址
  • 源端口
  • 目的地址
  • 目的端口

• 有一个 IP 的服务器监听了一个端口，它的 TCP 的最大连接数是多少？

• 

• TCP 和 UDP 区别： 7个

  1. 连接

  • TCP 是面向连接的传输层协议，传输数据前先要建立连接。
  • UDP 是不需要连接，即刻传输数据。

  2. 服务对象

  • TCP 是一对一的两点服务，即一条连接只有两个端点。
  • UDP 支持一对一、一对多、多对多的交互通信

  3. 可靠性

  • TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
  • UDP 是尽最大努力交付，不保证可靠交付数据。

  4. 拥塞控制、流量控制

  • TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
  • UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

  5. 首部开销

  • TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
  • UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

  6. 传输方式

  • TCP 是流式传输，没有边界，但保证顺序和可靠。
  • UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

  7. 分片不同

  • TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
  • UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层。

  TCP 和 UDP 应用场景：

  由于 TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：

  • FTP 文件传输；
  • HTTP / HTTPS；

  由于 UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：

  • 包总量较少的通信，如 DNS 、SNMP 等；
  • 视频、音频等多媒体通信；
  • 广播通信；

tcp连接建立 5条

• 一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态

• 客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态

• 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态

• 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态

• 服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态

• 从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题

• 如何在 Linux 系统中查看 TCP 状态？ netstat -napt

• 为什么是三次握手？不是两次、四次？

  相信大家比较常回答的是：“因为三次握手才能保证双方具有接收和发送的能力。”

  这回答是没问题，但这回答是片面的，并没有说出主要的原因。

  在前面我们知道了什么是 TCP 连接：

  • 用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接。

  所以，重要的是为什么三次握手才可以初始化Socket、序列号和窗口大小并建立 TCP 连接。

  接下来，以三个方面分析三次握手的原因： 三次握手的首要原因是为了防止旧的重复连接初始化造成混乱

  • 三次握手才可以阻止重复历史连接的初始化（主要原因）
  • 三次握手才可以同步双方的初始序列号
  • 三次握手才可以避免资源浪费

TCP 连接断开 7条

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。
• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
• 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
• 服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。
• 客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

为什么挥手需要四次？

再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次

为什么 TIME_WAIT 等待的时间是 2MSL？

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

比如，如果被动关闭方没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。

可以看到 2MSL时长 这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对。

为什么不是 4 或者 8 MSL 的时长呢？你可以想象一个丢包率达到百分之一的糟糕网络，连续两次丢包的概率只有万分之一，这个概率实在是太小了，忽略它比解决它更具性价比。

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

在 Linux 系统里 2MSL 默认是 60 秒，那么一个 MSL 也就是 30 秒。Linux 系统停留在 TIME_WAIT 的时间为固定的 60 秒。

TCP 重传、滑动窗口、流量控制、拥塞控制

• 今天，将重点介绍 TCP 的重传机制、滑动窗口、流量控制、拥塞控制。 可靠传输的保证！！！

• 重传机制 TCP 实现可靠传输的方式之一，是通过序列号与确认应答

  • 在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息
  • 所以 TCP 针对数据包丢失的情况，会用重传机制解决
  • 常见的重传机制：
    • 超时重传 RTT 指的是数据发送时刻到接收到确认的时刻的差值，也就是包的往返时间 超时重传时间是以 RTO （Retransmission Timeout 超时重传时间）表示
      • 有两种超时时间不同的情况：
        • 当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；
        • 当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发
      • 超时重传时间 RTO 的值应该略大于报文往返 RTT 的值
      • 实际上「报文往返 RTT 的值」是经常变化的，因为我们的网络也是时常变化的。也就因为「报文往返 RTT 的值」 是经常波动变化的，所以「超时重传时间 RTO 的值」应该是一个动态变化的值
    • 快速重传 它不以时间为驱动，而是以数据驱动重传
    • SACK Selective Acknowledgment 选择性确认 只重传丢失的数据
    • D-SACK

• 滑动窗口

  • 那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值

  • 窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除

  • 假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」

  • 这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

    所以，通常窗口的大小是由接收方的窗口大小来决定的

• 流量控制

  • 如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。
  • 为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制

• 拥塞控制

  • 前面的流量控制是避免「发送方」的数据填满「接收方」的缓存，但是并不知道网络的中发生了什么。
  • 在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大.
  • 于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络
  • 拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的
  • 我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值

• 拥塞控制的慢启动

  • 慢启动

    TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量，如果一上来就发大量的数据，这不是给网络添堵吗？

    慢启动的算法记住一个规则就行：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1

  • 慢启动算法，发包的个数是指数性的增长

鹅厂：因为如果 FIN 报文比数据包先抵达客户端，此时 FIN 报文其实是一个乱序的报文，此时客户端的 TCP 连接并不会从 FIN_WAIT_2 状态转换到 TIME_WAIT 状态

• 在 FIN_WAIT_2 状态时，如果收到乱序的 FIN 报文，那么就被会加入到「乱序队列」，并不会进入到 TIME_WAIT 状态
• 等再次收到前面被网络延迟的数据包时，会判断乱序队列有没有数据，然后会检测乱序队列中是否有可用的数据，如果能在乱序队列中找到与当前报文的序列号保持的顺序的报文，就会看该报文是否有 FIN 标志，如果发现有 FIN 标志，这时才会进入 TIME_WAIT 状态

ip篇

• IP 在 TCP/IP 参考模型中处于第三层，也就是网络层。
• 网络层的主要作用是：实现主机与主机之间的通信，也叫点对点（end to end）通信

DNS 域名解析，DNS 可以将域名网址自动转换为具体的 IP 地址

通过 ARP 协议，求得下一跳的 MAC 地址

DHCP 动态获取 IP 地址

于是，提出了一种网络地址转换 NAT 的方法，再次缓解了 IPv4 地址耗尽的问题。

ICMP 全称是 Internet Control Message Protocol，也就是互联网控制报文协议 ICMP 主要的功能包括：确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等

IGMP 是因特网组管理协议，工作在主机（组播成员）和最后一跳路由之间

ping的工作原理

• IP协议的助手 —— ICMP 协议 : ICMP 全称是 Internet Control Message Protocol，也就是互联网控制报文协议
• ICMP 主要的功能包括：确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等
• 在 IP 通信中如果某个 IP 包因为某种原因未能达到目标地址，那么这个具体的原因将由 ICMP 负责通知
• ping 命令执行的时候，源主机首先会构建一个 ICMP 回送请求消息数据包
• ICMP 数据包内包含多个字段，最重要的是两个：
  • 第一个是类型，对于回送请求消息而言该字段为 8；
  • 另外一个是序号，主要用于区分连续 ping 的时候发出的多个数据包
• 说了这么多，可以看出 ping 这个程序是使用了 ICMP 里面的 ECHO REQUEST（类型为 8 ） 和 ECHO REPLY （类型为 0）

部分资料来自于图解网络