计算机网络查漏补缺.md

计算机网络查漏补缺

基础篇

2.1 TCP/IP 网络模型有哪几层？

综上所述，TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层。

再给大家贴一下每一层的封装格式：

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

2.2 键入网址到网页显示，期间发生了什么？

2.3 Linux 系统是如何收发网络包的？

电脑与电脑之间通常都是通话网卡、交换机、路由器等网络设备连接到一起，那由于网络设备的异构性，国际标准化组织定义了一个七层的 OSI 网络模型，但是这个模型由于比较复杂，实际应用中并没有采用，而是采用了更为简化的 TCP/IP 模型，Linux 网络协议栈就是按照了该模型来实现的。

TCP/IP 模型主要分为应用层、传输层、网络层、网络接口层四层，每一层负责的职责都不同，这也是 Linux 网络协议栈主要构成部分。

当应用程序通过 Socket 接口发送数据包，数据包会被网络协议栈从上到下进行逐层处理后，才会被送到网卡队列中，随后由网卡将网络包发送出去。

而在接收网络包时，同样也要先经过网络协议栈从下到上的逐层处理，最后才会被送到应用程序。

HTTP篇

3.1 HTTP 常见面试题

3.2 HTTP/1.1如何优化？

这次主要从 3 个方面介绍了优化 HTTP/1.1 协议的思路。

第一个思路是，通过缓存技术来避免发送 HTTP 请求。客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。

第二个思路是，减少 HTTP 请求的次数，有以下的方法：

1. 将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；
2. 将多个小资源合并成一个大资源再传输，能够减少 HTTP 请求次数以及 头部的重复传输，再来减少 TCP 连接数量，进而省去 TCP 握手和慢启动的网络消耗；
3. 按需访问资源，只访问当前用户看得到/用得到的资源，当客户往下滑动，再访问接下来的资源，以此达到延迟请求，也就减少了同一时间的 HTTP 请求次数。

第三思路是，通过压缩响应资源，降低传输资源的大小，从而提高传输效率，所以应当选择更优秀的压缩算法。

不管怎么优化 HTTP/1.1 协议都是有限的，不然也不会出现 HTTP/2 和 HTTP/3 协议，后续我们再来介绍 HTTP/2 和 HTTP/3 协议

3.3 HTTPS RSA 握手解析

3.4 HTTPS ECDHE 握手解析

RSA 和 ECDHE 握手过程的区别：

• RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；
• 使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间；
• 使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息；

3.5 HTTPS 如何优化？

对于硬件优化的方向，因为 HTTPS 是属于计算密集型，应该选择计算力更强的 CPU，而且最好选择支持 AES-NI 特性的 CPU，这个特性可以在硬件级别优化 AES 对称加密算法，加快应用数据的加解密。

对于软件优化的方向，如果可以，把软件升级成较新的版本，比如将 Linux 内核 2.X 升级成 4.X，将 openssl 1.0.1 升级到 1.1.1，因为新版本的软件不仅会提供新的特性，而且还会修复老版本的问题。

对于协议优化的方向：

• 密钥交换算法应该选择 ECDHE 算法，而不用 RSA 算法，因为 ECDHE 算法具备前向安全性，而且客户端可以在第三次握手之后，就发送加密应用数据，节省了 1 RTT。
• 将 TSL1.2 升级 TSL1.3，因为 TSL1.3 的握手过程只需要 1 RTT，而且安全性更强。

对于证书优化的方向：

• 服务器应该选用 ECDSA 证书，而非 RSA 证书，因为在相同安全级别下，ECC 的密钥长度比 RSA 短很多，这样可以提高证书传输的效率；
• 服务器应该开启 OCSP Stapling 功能，由服务器预先获得 OCSP 的响应，并把响应结果缓存起来，这样 TLS 握手的时候就不用再访问 CA 服务器，减少了网络通信的开销，提高了证书验证的效率；

对于重连 HTTPS 时，我们可以使用一些技术让客户端和服务端使用上一次 HTTPS 连接使用的会话密钥，直接恢复会话，而不用再重新走完整的 TLS 握手过程。

常见的会话重用技术有 Session ID 和 Session Ticket，用了会话重用技术，当再次重连 HTTPS 时，只需要 1 RTT 就可以恢复会话。对于 TLS1.3 使用 Pre-shared Key 会话重用技术，只需要 0 RTT 就可以恢复会话。

这些会话重用技术虽然好用，但是存在一定的安全风险，它们不仅不具备前向安全，而且有重放攻击的风险，所以应当对会话密钥设定一个合理的过期时间。

3.6 HTTP/2 牛逼在哪？

HTTP/2 协议其实还有很多内容，比如流控制、流状态、依赖关系等等。

这次主要介绍了关于 HTTP/2 是如何提示性能的几个方向，它相比 HTTP/1 大大提高了传输效率、吞吐能力。

第一点，对于常见的 HTTP 头部通过静态表和 Huffman 编码的方式，将体积压缩了近一半，而且针对后续的请求头部，还可以建立动态表，将体积压缩近 90%，大大提高了编码效率，同时节约了带宽资源。

不过，动态表并非可以无限增大， 因为动态表是会占用内存的，动态表越大，内存也越大，容易影响服务器总体的并发能力，因此服务器需要限制 HTTP/2 连接时长或者请求次数。

第二点，HTTP/2 实现了 Stream 并发，多个 Stream 只需复用 1 个 TCP 连接，节约了 TCP 和 TLS 握手时间，以及减少了 TCP 慢启动阶段对流量的影响。不同的 Stream ID 才可以并发，即时乱序发送帧也没问题，但是同一个 Stream 里的帧必须严格有序。

另外，可以根据资源的渲染顺序来设置 Stream 的优先级，从而提高用户体验。

第三点，服务器支持主动推送资源，大大提升了消息的传输性能，服务器推送资源时，会先发送 PUSH_PROMISE 帧，告诉客户端接下来在哪个 Stream 发送资源，然后用偶数号 Stream 发送资源给客户端。

HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。

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

有没有什么解决方案呢？既然是 TCP 协议自身的问题，那干脆放弃 TCP 协议，转而使用 UDP 协议作为传输层协议，这个大胆的决定， HTTP/3 协议做了！

3.7 HTTP/3 强势来袭

HTTP/2 虽然具有多个流并发传输的能力，但是传输层是 TCP 协议，于是存在以下缺陷：

• 队头阻塞，HTTP/2 多个请求跑在一个 TCP 连接中，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是多个请求被阻塞了；
• TCP 和 TLS 握手时延，TCL 三次握手和 TLS 四次握手，共有 3-RTT 的时延；
• 连接迁移需要重新连接，移动设备从 4G 网络环境切换到 WIFI 时，由于 TCP 是基于四元组来确认一条 TCP 连接的，那么网络环境变化后，就会导致 IP 地址或端口变化，于是 TCP 只能断开连接，然后再重新建立连接，切换网络环境的成本高；

HTTP/3 就将传输层从 TCP 替换成了 UDP，并在 UDP 协议上开发了 QUIC 协议，来保证数据的可靠传输。

QUIC 协议的特点：

• 无队头阻塞，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，也不会有底层协议限制，某个流发生丢包了，只会影响该流，其他流不受影响；
• 建立连接速度快，因为 QUIC 内部包含 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。
• 连接迁移，QUIC 协议没有用四元组的方式来“绑定”连接，而是通过「连接 ID 」来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本；

另外 HTTP/3 的 QPACK 通过两个特殊的单向流来同步双方的动态表，解决了 HTTP/2 的 HPACK 队头阻塞问题。

TCP篇

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

小结

TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号**。序列号能够保证数据包不重复、不丢弃和按序传输。

不使用「两次握手」和「四次握手」的原因：

• 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
• 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

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

4.3 TCP 实战抓包分析

4.4 TCP 半连接队列和全连接队列

4.5 如何优化 TCP?

4.6 如何理解是 TCP 面向字节流协议？

4.7 为什么 TCP 每次建立连接时，初始化序列号都要不一样呢？

4.8 SYN 报文什么时候情况下会被丢弃？

1、开启了一个设置 然后因为网络原因收到的数据包时间戳不是递增的就丢弃了

2、accept满了，半连接或者全连接

4.9 已建立连接的TCP，收到SYN会发生什么？

根据你客户端syn报文中的源端口有关，如果源端口是不一致的话，则重新建立连接，如一致的话，看源码也是会断开相应连接

如何关闭一个TCP连接伪造RST报文 这样就可以让它们释放连接了

4.10 四次挥手中收到乱序的 FIN 包会如何处理？

在 FIN_WAIT_2 状态时，如果收到乱序的 FIN 报文，那么就被会加入到「乱序队列」，并不会进入到 TIME_WAIT 状态。

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

4.11 在 TIME_WAIT 状态的 TCP 连接，收到 SYN 后会发生什么？

在 TCP 正常挥手过程中，处于 TIME_WAIT 状态的连接，收到相同四元组的 SYN 后会发生什么？

如果双方开启了时间戳机制：

• 如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大，并且SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要大。那么就会重用该四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。
• 如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小，或者SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要小。那么就会再回复一个第四次挥手的 ACK 报文，客户端收到后，发现并不是自己期望收到确认号，就回 RST 报文给服务端。

在 TIME_WAIT 状态，收到 RST 会断开连接吗？

• 如果 net.ipv4.tcp_rfc1337 参数为 0，则提前结束 TIME_WAIT 状态，释放连接。
• 如果 net.ipv4.tcp_rfc1337 参数为 1，则会丢掉该 RST 报文。

4.12 TCP 连接，一端断电和进程崩溃有什么区别？

在没有有开启去keep-alive且无数据传输的情况下

断电的话服务端的TCP连接将会一直处于已建立连接状态

进程崩溃的话 会发送fin进行挥手 是可以感知到的

有数据传输情况下的问题

客户端主机宕机又迅速重启-只要有一方重启完成后收到之前的TCP连接的报文都会回复RST报文，以断开连接

客户端主机宕机，一直没有重启，会重传，先到达最大重传次数或者最大超时时间其中一个条件后，就会停止重传

4.13 拔掉网线后， 原本的 TCP 连接还存在吗？

客户端拔掉网线后，并不会直接影响 TCP 连接状态。所以，拔掉网线后，TCP 连接是否还会存在，关键要看拔掉网线之后，有没有进行数据传输。

有数据传输的情况：

• 在客户端拔掉网线后，如果服务端发送了数据报文，那么在服务端重传次数没有达到最大值之前，客户端就插回了网线，那么双方原本的 TCP 连接还是能正常存在，就好像什么事情都没有发生。
• 在客户端拔掉网线后，如果服务端发送了数据报文，在客户端插回网线之前，服务端重传次数达到了最大值时，服务端就会断开 TCP 连接。等到客户端插回网线后，向服务端发送了数据，因为服务端已经断开了与客户端相同四元组的 TCP 连接，所以就会回 RST 报文，客户端收到后就会断开 TCP 连接。至此， 双方的 TCP 连接都断开了。

没有数据传输的情况：

• 如果双方都没有开启 TCP keepalive 机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，那么客户端和服务端的 TCP 连接状态将会一直保持存在。
• 如果双方都开启了 TCP keepalive 机制，那么在客户端拔掉网线后，如果客户端一直不插回网线，TCP keepalive 机制会探测到对方的 TCP 连接没有存活，于是就会断开 TCP 连接。而如果在 TCP 探测期间，客户端插回了网线，那么双方原本的 TCP 连接还是能正常存在。

除了客户端拔掉网线的场景，还有客户端「宕机和进程崩解」的两种场景。

第一个场景，客户端宕机这件事跟拔掉网线是一样无法被服务端的感知的，所以如果在没有数据传输，并且没有开启 TCP keepalive 机制时，，服务端的 TCP 连接将会一直处于 ESTABLISHED 连接状态，直到服务端重启进程。

所以，我们可以得知一个点。在没有使用 TCP 保活机制，且双方不传输数据的情况下，一方的 TCP 连接处在 ESTABLISHED 状态时，并不代表另一方的 TCP 连接还一定是正常的。

第二个场景，客户端的进程崩解后，客户端的内核就会向服务端发送 FIN 报文，与服务端进行四次挥手。

所以，即使没有开启 TCP keepalive，且双方也没有数据交互的情况下，如果其中一方的进程发生了崩溃，这个过程操作系统是可以感知的到的，于是就会发送 FIN 报文给对方，然后与对方进行 TCP 四次挥手。

4.14 tcp_tw_reuse 为什么默认是关闭的？

tcp_tw_reuse 的作用是让客户端快速复用处于 TIME_WAIT 状态的端口，相当于跳过了 TIME_WAIT 状态，这可能会出现这样的两个问题：

• 历史 RST 报文可能会终止后面相同四元组的连接，因为 PAWS（防止序列号回绕） 检查到即使 RST 是过期的，也不会丢弃。
• 如果第四次挥手的 ACK 报文丢失了，有可能被动关闭连接的一方不能被正常的关闭;

虽然 TIME_WAIT 状态持续的时间是有一点长，显得很不友好，但是它被设计来就是用来避免发生乱七八糟的事情。

4.15 HTTPS 中 TLS 和 TCP 能同时握手吗？

「HTTPS 是先进行 TCP 三次握手，再进行 TLSv1.2 四次握手」，这句话一点问题都没有，怀疑这句话是错的人，才有问题。

「HTTPS 中的 TLS 握手过程可以同时进行三次握手」，这个场景是可能存在到，但是在没有说任何前提条件，而说这句话就等于耍流氓。需要下面这两个条件同时满足才可以：

• 客户端和服务端都开启了 TCP Fast Open 功能，且 TLS 版本是 1.3；
• 客户端和服务端已经完成过一次通信；

4.16 TCP Keepalive 和 HTTP Keep-Alive 是一个东西吗？

HTTP 的 Keep-Alive 也叫 HTTP 长连接，该功能是由「应用程序」实现的，可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

TCP 的 Keepalive 也叫 TCP 保活机制，该功能是由「内核」实现的，当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接。

4.17 TCP 协议有什么缺陷？

IP篇

5.1 IP 基础知识全家桶

5.2 ping 的工作原理

自己记录的问题

• TCP/IP网络模型属于网络通信的一套通用的网络协议

• 应用层是工作在操作系统的用户态，传输层及以下则工作在内核态

• MSS（TCP最大报文段长度）

• 传输层的报文会携带端口号的，因此接收方可以识别出该报文是发送给哪个应用

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

• IP地址主要分成两种意义，一个是网络号，一个是主机号，根据掩码可以获取两者

• IP 协议的寻址作用是告诉我们去往下一个目的地==该朝哪个方向走==，路由则是==根据「下一个目的地」选择路径==。寻址更像在导航，路由更像在操作方向盘。自己用通俗的话讲一遍就是这个ip告诉我们最终要去哪个网络的哪台主机，路由的话就是咋去，遇到个路由器给他看，他帮你分配

• 网络接口层会将网络层的数据封装成帧，根据mac头部进行转发

• ⭐其实我们访问对应的网址后面一系列的东西，其实最后都是请求他实际的域名的 比如https://www.baidu.com/s?wd=杭州电子科技大学&rsv_spt=1&rsv_iqid=0xc992c3e7004b9c01&issp=1&f=8&rsv_bp=1&rsv_idx=2&ie=utf-8 类似于这一段其实就是请求百度，后面是数据源的数据名，用来生成相应的请求报文发送给服务器域名进行请求

• 必须用到DNS因为委托操作系统发送消息的时候，必须提供通信对象的IP地址（浏览器中会有域名的缓存，每次都会先看是否有缓存，再去请求DNS）

• MTU：一个网络包的最大长度，以太网中一般为 1500 字节。 MSS：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度。

• TCP报文的源端口随机生成，目的端口根据你的请求，如果是HTTP请求那就是80 如果是其他就是其他规定的端口

• TCP可靠传输 可以看看他的报文头部

• 搞清楚 包发给谁 查一下路由表，根据路由表获得的ip然后使用arp协议找到对应路由器的mac地址，操作系统也会有arp缓存 不是每次都要广播获取

• 在网络包传输的过程中，源 IP 和目标 IP 始终是不会变的，一直变化的是 MAC 地址，因为需要 MAC 地址在以太网内进行两个设备之间的包传输。

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

• GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。

  POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存。 （但不完全是这样 可以用get实现新增和删除那就不是安全和幂等了，用post实现查询，那就是安全和幂等）

• GET请求其实也是可以带上body的同时POST请求的URL中也可以有参数

• HTTP（1.1）优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

• HTTP（1.1）性能 1、长连接 2、管道网络传输 3、响应队头阻塞

• SSL/TLS 协议基本流程：

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

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

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

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

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

• HTTP/2 相比 HTTP/1.1 性能上的改进：1、头部压缩 2、二进制格式 （原来传200 用三个字符转成二进制 24位 现在200直接一个8位的就解决掉了）3、数据流 4、多路复用 5、服务器推送

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

• HTTP/3 优化：使用了QUIC+UDP QUIC可以实现类似TCP的可靠传输 有以下特点1、无队头阻塞 2、更快的连接建立 3、连接迁移

• HTTPS常用的密钥交换算法有两种，分别是RSA和ECDHE算法

• rsa整个加密过程已经过的很舒服了，比起第一次看，这次看真的懂了很多（rsa没有前向安全性 参考下面）

• 【前向安全性】：前向安全性或前向保密性（英语：Forward Secrecy，缩写：FS），有时也被称为完美前向安全（英语：Perfect Forward Secrecy，缩写：PFS），是密码学中通讯协议的安全属性，指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。

• HTTPS的优化 硬件优化 软件优化 会话复用 协议优化 证书优化

• 两次握手，无法避免历史连接 三次握手同步双方初始序列号

• 如果单纯知识ip进行分片的话，是没有效率的，所以要有tcp分片

• 第一次握手丢失 客户端触发超时重传 第二次握手丢失 服务端、客户端触发超时重传 第三次握手丢失 服务端超时重传

• 三次握手成功后才是真正的应用 才是进行socket连接 就是accept

• 第一次挥手丢失了 客户端会进行重传，超过重传的次数还没得到应答的后，会直接进行close状态

• 不管有没有收到第二次挥手，客户端到后面都会处于fin_wait2状态

• 内核是没有权利替代进程关闭连接，所以必须由进程主动调用close函数来触发服务端发送Fin

• MSL报文最大生存时间，MSL要大于TTL（IP数据包可以经过的最大路由数）消耗为0的时间，以确保报文已被自然消亡

• 主动发起连接的一方，才会有TIME-WAIT状态，需要这状态的两个原因，1、防止历史连接中的数据被后面相同四元组的错误接收 2、保证被动连接的一方能被正确关闭

• socket tcp 客户端connect成功返回在第二次握手 服务端accept成功返回在第三次握手

• RTT是数据发送时刻到接收到确认的时刻的差值（经常动态变化的值） RTO是超时重传时间 应该是略大于RTT不能太长也不能太短（也会是经常动态变化）

• 快速重传机制，它不以时间为驱动，而是以数据驱动重传 其中还有两个其他实现重传的机制 SACK D-SACK

• 接收窗口和发送窗口大小并不是完全相等的，因为传输过程是存在时延的，所以接收窗口和发送窗口是约等于关系

• 糊涂窗口综合症 一点小数据也发 甚至还比不上TCP+的头要解决糊涂窗口综合症，就解决上面两个问题就可以了

  • 让接收方不通告小窗口给发送方（解决方法：当窗口小于min（MSS，缓存空间/2）就像发送方通告窗口大小为0）
  • 让发送方避免发送小数据（解决方法：Nagle算法 满足以下两个条件之一才可以发送数据：要等到窗口大小 >= MSS 或是数据大小>= MSS/////或者收到之前发送数据的ack回包）

• 流量控制只是端到端的 拥塞控制很明显是应对整个网络中的环境

• swnd = min(cwnd, rwnd) 发送窗口为拥塞窗口和接收窗口的小值，我之前想的有点偏差，之前看那个拥塞窗口一直变大，觉得会传很多，原来是拥塞和发送窗口的小值，这下明白了所以说还是要多想想

• 拥塞窗口每收到一个ack+1，当超过慢启动门限后每超过一个窗口确认加1/cwnd，所以慢启动门限后所有的拥塞窗口都收到了 才+1

• TCP解决粘包有三种方式：固定长度的消息；特殊字符作为边界（如果消息内部出现这个特殊字符的时候 需要对这个字符进行转义）；自定义消息结构

• 只有主动关闭的才有time_wait状态

• MSL是由网络层的IP包中的TTL来保证的，TTL是IP头部的一个字段，用于设置一个数据报可经过的路由器数量上限

• 设置time_wait的两大原因一定是要清楚

• TCP第三次握手是可以携带数据的

• TCP三次握手之后才能进行TLS1.2四次握手

• 开启了TCP Fast Open之后 接收到客户端的请求，同时验证了cookie后响应ack 可立刻传输数据

• HTTP的Keep-Alive是长连接 TCP的Keep-Alive是TCP保活机制

• 传输层是针对进程间的传输 网络层是针对主机间的传输

• 数据链路层其实就是在没有直连之间的网络间中各个设备间的传输

• IP地址中有两个IP是特殊的，分别是主机号全为1和全为0地址 全为1就是广播地址 全为0就是指定对应的网络

• 有直接广播和本地广播 要知道是什么意思

• ip分类其实就是能很快的判断分类 很快的找出网络地址和主机地址

• 对某类地址可以再进行子网划分

• 公有ip地址和私有ip地址 我们用的基本都是私有ip

• DNS 有查询缓存的过程

• ARP协议也是有查询缓存的过程，同时，但是换船是一定期限的，超过期限会删除 ARP会动态执行

• DHCP动态获取IP地址 动态的请求服务器 获取相应的地址 也类似于有四次握手 用UDP广播通信 因为有路由器转发请求 所以不在一个网络内也没事 交互完成后 客户端能在租用期内使用服务器分配的ip地址

• NAT网络地址转换

  网络地址与端口转换 NAPT两个不同的私有ip可以转换为一个公有ip以不同的端口号进行区分 会生成相应的路由转换表

• ICMP 全称是 Internet Control Message Protocol，也就是互联网控制报文协议。 从哪里丢失 就从哪里发回去 分为两类
  一类用于诊断的查询消息 也就是查询报文类型
  另一类通知出错原因的错误消息 也就是差错报文类型

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

• ping 用的是ICMP查询报文
  traceroute 用的是ICMP差错报文