一、基础篇

1.1 TCP/IP 网络模型

应用层-按既定协议打包数据

专注于为用户提供功能。以某种统一规定的协议格式解读数据。

应用层按既定协议打包数据，由传输层加上双方的端口，由网络层加上双方IP地址，由链路层加上双方MAC地址【数据拆成数据帧，经过多个路由器+网关后】。

传输层【端口】（TCP+UDP）-加上双方的端口

定义逻辑端口（UDP、TCP）
为应用层提供网络支持，作为应用间数据传输的媒介，帮助实现应用到应用的通信。
数据包长度大于MSS[最大报文段长度]，数据包就要分块。

网络层（IP协议）-加上双方IP地址

传输功能。IP协议会将传输层的报文作为数据部分，加上IP包头组装成IP报文。IP报文若超过MTU[最大传输单元]，则会进行分片。
IP协议的寻址作用就是告诉我们去往下一个目的地该朝哪个方向走，路由则是根据【下一个目的地】选择路径。

• IP地址作用：在WLAN内进行路由寻址，选择最佳路由。

• IP报头中包含TTL（生存时间）数据包在传输过程中没经过一个路由器则减1，当其为0时，发送ICMP报文通知源主机，防止源主机无休止发送报文。ICMP就是检测网络通畅的协议，ping、tracert基于此。
  数据链路层【MAC】
  用来标识网络中的设备，让数据再一个链路中传输。路由器计算出下一个目的地的IP地址，再通过ARP协议找到该目的地的MAC地址。
  以字节为单位把0与1进行分组，定义数据帧。写入源和目标机器的物理地址、数据、校验位来传输数据。
  物理层
  为数据链路层提供二进制传输的服务。

  数据链路层【MAC】-加上双方MAC地址

  以字节为单位把0与1进行分组，定义数据帧。写入源和目标机器的物理地址、数据、校验位来传输数据。传输有地址的数据帧+错误检测（ARP）

  二、HTTP篇

  2.1 HTTP常见面试题

  HTTP 是一个计算机世界里专门在【两点】之间【传输】文字、图片、音频等【超文本】数据的【约定和规范】。（简单、灵活和易于扩展、应用广泛和跨平台）

• http工作在应用层（OSI第七层），下层可以随意变换。HTTPS就是在HTTP与TCP层之间增加了SSL/TLS安全传输层。

• http1.1默认keep-alive，使得管道（pipeline）网络传输成为可能。管道机制允许浏览器同时发出A请求+B请求。服务器会按顺序回应。但是【请求-应答】模式加剧了HTTP性能问题，【队头阻塞(所有请求在一个FIFO队列里，如果队头请求意外阻塞，这样就会造成队头阻塞。)】会导致客户端请求不到数据。HTTP/2解决了用流和分帧的方式HTTP的队头阻塞问题。HTTP/3解决了用UDP+QUIC解决了TCP队头阻塞的问题。
• https混合加密（机密性） + 摘要算法（完整性）+数字证书（冒充问题）

  HTTPS比HTTP多了什么？

1. 建立链接时。多了TLS握手的过程。

2. 传输内容时。对称加密数据。

   HTTP1.1性能如何

3. 长连接 ： HTTP/1.1提出，减少TCP重复链接带来的开销。

4. 管道网络传输：HTTP/1.1客户端可以发起多个请求，但服务器还是按照顺序回应请求。前面的回应比较慢会出现【队头阻塞】。
   问题：pipline中一个请求堵塞，其它请求也会堵塞。

   HTTP2 （浏览器Protocol能看见为h2）

5. 头部压缩。消除一组请求重复的请求头。

6. 二进制格式。头信息和数据体都是二进制。
7. 数据流。数据包不按顺序发送，请求/回应的数据包叫做数据流。
8. 多路复用。一个连接中并发多个请求或回应，不用按顺序对应。消除了【队头阻塞】问题。
9. 服务器推送。不是只被动的响应，提前把静态资源返回给前端。
   问题：多个请求复用一个TCP链接，一旦丢包，需要全部重传，会阻塞住所有的HTTP请求。（TCP必须保证收到的字节数据是完整且连续的，这样内核才会把缓冲区中的数据返回给HTTP应用）

   HTTP3

   将HTTP下层的TCP协议改成了UDP。基于UDP的QUIC协议（伪TCP+TLS+HTTP/2）可以实现类似TCP的可靠性传输。

• QUIC有自己的机制确保传输的可靠性。某个流丢包时，只会阻塞这个流。
• QUIC将TCP和TLS/1.3的6次交互合并成了3次，减少了交互次数。
  QUIC是新协议，很多网络设备不认识，只会当作是UDP。

  2.2 HTTP1.1如何优化

  1.尽量避免发送HTTP请求。(缓存)

  通过缓存技术。发送HTTP响应时，会估算一个过期的时间。当缓存过期，客户端重新发送请求，若服务器发送缓存还能用，会仅返回不含有包体的304 Not Modified响应。

  2.发送HTTP请求时，考虑减少请求次数。

1. 减少重定向请求次数。重定向交由代理服务器完成。
2. 合并请求。（合并多个小图片成一个大图片【合并资源】，减少HTTP请求次数）
3. 延迟发送请求。页面【按需获取】资源。
4. 减少服务器HTTP响应的数据大小。
5. 无损压缩。客户端支持的压缩算法会在请求头中告诉服务器。Accept-Encoding: gzip, deflate, br。 服务器会选择一种Content-Encoding: gzip

6. 有损压缩。用于压缩多媒体数据。HTTP请求头Accept中【q质量因子】

   2.3 HTTPS RSA握手解析-不支持前向保密

   TLS握手过程

   TLS解决了HTTP的风险。

7. 信息加密。

8. 校验机制。
9. 身份证书。

RSA密钥协商算法的最大问题时不支持前向保密。服务端的私钥泄露，以往的TLS报文就会别泄露。后面出现了ECDHE密钥协商算法。

2.4 HTTPS ECDHE握手解析

RSA是比较传统的密钥交换算法，但不具备前向保密。而ECDHE前向安全，被广泛使用。

离散对数
再对数运算的基础上加了【模运算（模很大）】，很难去算出对数的值。

DH算法
客户端、服务端生成随机整数作为私钥a、b（不能泄露），公开模数P、G。大家都能算到公钥。
A = G^a(mod P) B = G^b(mod P) 如果P是大数，则破解不出来私钥。

DHE算法
双方的私钥在每次密钥交换时，都是随机生成的，临时的。

ECDHE算法
在DHE的基础上，利用ECC的椭圆曲线，利用更小的计算量计算公钥。

RSA与ECDHE的区别：

1. RSA密钥协商算法不支持【前向保密】
2. ECDHE相比RSA握手过程省去了一个消息的往返时间，在链接没完全建立好之前就发送了数据。类似tcp fast open。 而RSA不行。

3. ECDHE在TLS第二次握手中，会出现服务器端发出的【server key exchange】消息。

   2.5 HTTPS优化

   1.硬件优化

   HTTPS是计算密集型。CPU可以选择指令级别优化了AES算法的CPU。

   2.软件优化

   升级软件，Linux内核、OpenSSL。

   3.协议优化

4. 密钥交换算法
   RSA密钥交换需要4次握手花费2RTT，不具备前向安全性。
   应该用ECDHE密钥交换算法替换它。客户端在TLS第3次握手后，可以发送消息。1RTT，有前向安全性。

5. TLS升级
   TLS1.3 简化了握手过程（把Hello和公钥交换这两个消息合并成了一个消息）。完成TLS只需要1RTT。并且只支持ECDHE密钥交换算法。

   4.证书优化

6. 证书传输优化。减少证书的大小，选用ECDSA证书，而不是RSA证书。

7. 证书验证优化。OCSP Stapling 服务器向CA周期性地查询证书状态，获得一个带有时间戳和前面的响应结果并缓存它。

   5.会话复用-复用密钥，减少TLS握手的损耗，有安全风险

   会话复用都有的问题：前向安全、重放攻击

Session ID【1RTT】
客户端和服务器首次TLS握手连接后，双方会在内存缓存会话密钥，并用唯一的SessionId来标识。（服务器内存压力大，sessionId会被负载均衡失效）
Session Ticket【1RTT】
类似与HTTP cookie，缓存的工作交给客户端。确保每台服务器加密【会话密钥】的密钥是一致的。（需要对它设置一个合理的过期时间）
TLS1.3 Pre-shared Key【0RTT】
原理与Session Ticket类似，但重连时客户端会把Ticket和HTTP一同发送给服务端。

2.6 HTTP/2 牛逼在哪

头部压缩

1.1协议可以使用头字段【Content-Encoding】指定Body的压缩方式，但对于头部没有优化手段。
HTTP2开发了HPACK算法（动态字典+静态字典+Huffman编码）客户端与服务端两端都会维护【字典】（key：value），用长度较小的索引号表示重复的字符串，再用Huffman编码压缩。
静态表只会存储61种高频出现在头部的字符串，当其在同一个连接上，重复传输完全相同的头部，就会往后面加数据-》动态表（web服务器会有http2_max_requests限制一个连接上能够传输的请求数量）

二进制帧

1.1文本格式改成了二进制格式传输，提升了传输效率，而且二进制使用位运算能更高效。

并发传输

多个stream复用一条TCP连接，达到并发的效果。并且不同的Stream帧可以乱序发送。

• 一个TCP连接包含多个Stream。
• Stream里包含多个Message，Message对应HTTP/1中的请求或响应（HTTP头部+包体）

• Message里包含多个Frame，Frame是HTTP2最小单位，以二进制压缩格式存放HTTP头部+包体

  服务器主动推送资源

  客户端发起的请求，必须使用奇数号Stream，服务器的主动推送使用偶数号Stream。服务器会告诉客户端接下来会在哪个Stream种发送包体。

  2.7 牛逼的HTTP3

  HTTP2协议基于TCP实现，有三个缺陷。队头阻塞、TCP与TLS的握手延迟（TLS1.2 四次握手，3个RTT）、网络迁移需要重新连接。
  另外TCP有【拥塞控制】特性，刚建立的TCP会有个【慢启动】过程。

  QUIC协议

  QUIC协议拥有类似TCP的连接管理、拥塞窗口、流量控制等特性。

• 无队头阻塞。UDP不关心数据包顺序，QUIC为每个数据包加了唯一标识，某一个Stream中的数据包丢失了，无法被读取，直到QUIC重传。但这条连接内其它Stream不受影响。

• 更快的连接建立。对于HTTP2，TCP（内核实现的传输层）和SSL（openssl库实现的表示层）是分层的。HTTP3的QUIC协议不与TLS分层，QUIC内部包含了TLS1.3，只需要1RTT（确认双方的连接ID）建立连接和密钥协商。
• 连接迁移。基于TCP的HTTP协议需要四元组（源IP、源端口、目的IP、目的端口）确定一条TCP连接，当4G切换到WIFI，意味着IP地址发生变化，需要重新建立连接。而QUIC使用连接ID标记通信的两个端点，只要保留着上下文信息（连接ID、TLS密钥），就可以无缝连接原连接。
  另外，QUIC通过两个特殊单向流同步双方的动态表。

  三、TCP篇

  为什么需要TCP呢？ IP层不可靠，不保证网络包的交付、不保证网络包的按序交付、不保证网络包的完整性。

3.1 TCP三次握手与四次挥手

TCP基本认识

• 面向连接（一对一）、可靠（保证报文一定到达）、字节流（消息没有边界，且有序）
• 头格式：序列号（解决网络包乱序）+确认应答号（解决不丢包）+控制位（ACK+RST+SYN+FIN）
• 建立一个TCP连接需要的客户端服务端共识：Socket（IP+端口号）、序列号（解决乱序问题）、窗口大小（流量控制）

• 最大TCP连接数理论=客户端的IP数*客户端的端口数 【这里还会有文件描述符限制、内存限制】

  UDP协议与TCP区别

• 连接：UDP不需要连接即刻传输数据。

• 服务对象：UDP还支持一对多、多对多交互通信。
• 首部开销：UDP首部比较简单，且固定不变开销小。目标+源端口、包长度（UDP首部和数据长度之和）、校验和（提供可靠UDP首部和数据）
• 可靠性：UDP尽最大努力交付，不保证可靠交付数据。
• 拥塞/流量控制：UDP没有流量控制，网络堵塞也不会影响它。
• 传输方式：TCP是流式传输（无边界，保证顺序可靠），UDP是一个包一个包发送（有边界，可能丢包乱序）
• 分片不同：TCP数据大小大于MSS，会在传输层进行分片。 UDP数据大小大于MTU会在IP层进行分片。
  MTU：一个网络包的最大长度。
  MSS：出去IP和TCP头部后，一个网络包能容纳TCP的最大长度。【TCP建立连接时候通常要协商双方的MSS值，当分片丢失，重发时也会以MSS为单位】

  为什么UDP头部没有【首部长度】字段？

  TCP有可变长的【选项】字段，UDP头部长度定长。

  为什么UDP头部有【包长度】字段，而TCP没有呢？

  为了网络设备硬件设计和处理方便，首部长度需要是4字节的整数倍。

TCP连接建立（面向连接的协议，使用前必须建立连接）

客户端connect成功在第二次握手。第三次握手是可以携带数据的，服务端accept成功实在三次握手之后。

Netstat -napt 查看TCP连接状态

为什么TCP一定需要三次握手？

1. 避免历史连接（每次建立连接都需要重新初始化一个序列号）。（如果【旧的SYN报文】比【新SYN报文】提前到了服务器，服务器返回了SYN+ACK，客户端可以返回RST中止历史连接）
2. 同步双方初始序列号。（一来一回才能确保【SYN报文（会携带初始序列号）】被可靠的同步）

3. 避免资源浪费。（客户端的SYN阻塞了，重复发送多次SYN报文，服务器会建立多个无效链接）

   如何避免SYN攻击

4. 修改Linux内核参数，控制队队列大小和当队列满时应该做什么处理。

5. tcp_syncookies: SYN队列满了后，后续请求不进入[SYN队列]。直接计算出一个cookie值，以SYN+ACK中的【序列号】返回客户端。服务器收到客户端的应答报文，直接放入到【Accept队列】。最后应用通过accept（）socket接口，从【Accept队列】取出连接。

TCP四次挥手

弃，同时发送ICMP报文通知源主机。
MSL要大于TTL消耗为0的时间，一来一回就需要2MSL。

为什么一定需要TIME_WAIT？

1. 防止旧链接的数据包（足以让两边的数据包都被丢弃，原有的数据包全部消失，这样新数据包一定是新连接产生的）

   A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

2. 保证被动关闭方的连接正确关闭。（如果时间太短，有可能第四次挥手的ACK报文丢失，被动关闭方一直在LAST_ACK。再收到连接，服务端会发送RST报文）

   确保有足够的时候让对方收到ACK包，如果被动关闭的那一方没有收到ACK包，就会触发被动关闭的端重发FIN包，一来一去所用的时间就是2MSL

listen时参数backlog的意义？Int listen（int socketfd, int backlog）

Linux内核会维护两个队列：

1. 未完成队列（SYN队列）：接收到一个SYN建立连接请求，处于SYN_RCVD。

2. 已完成连接队列（Accept队列）：已完成TCP三次握手，处于ESTABLISH状态。backlog就是accept队列

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

3. 超时重传【数据包丢失、确认应答丢失】（每当遇到一次超时重传，都会将下一次超时的时间间隔设为先前值得两倍。两次超时，就会说明网络环境差）

4. 快速重传【收到三个相同的ACK报文，重传丢失的报文段】。重传的时候重传之前的一个还是传所有？SACK/Duplicate SACK

   滑动窗口

   窗口大小：窗口大小就是无需等待确认应答，可以继续发送数据的最大值。
   窗口大小由谁决定（接收端）：TCP头部中有一个字段window，接收端会告诉发送端缓冲区大小。接受窗口和发送窗口不一定相等，大小是约等于关系。

   流量控制

   让【发送方】根据【接收方】实际接受能力控制发送的数据量。

   操作系统缓冲区与滑动窗口的关系

   发送窗口和接受窗口中的所接受窗口中所存放的字节数，都是放在操作系统内存缓存区（会被操作系统调整）中的。
   TCP规定不允许同时减少缓存又收缩窗口。它会先收缩窗口，过段时间后再减少缓存，避免了丢包情况。

   窗口关闭

   接受发向发送发通告窗口大小时，是通过ACK报文来通告的。
   当发生窗口关闭时，接收方处理完数据，会向发送方通告一个窗口非0的ack报文，如果丢失了，发送方和接收方都会去等待数据/通知，出现死锁。

   窗口关闭死锁怎么解决

   TCP连接一方收到对方的零窗口通知，会启动持续计时器。如果持续计时器超时，就会发送窗口探测报文，对方接收到后会回复现在接受窗口的大小。

   糊涂窗口综合症

   如果接收方太忙，来不及取走接收窗口里的数据，发送窗口就会越来越小。这时如果接受方腾出来几个字节并告诉了发送方，发送方会直接发送这几个字节。（TCP+IP头有40个字节，为了传输这几个字节，开销太大）

5. 让接收方不通告小窗口给发送方。

6. 让发送方避免发送小数据。

   拥塞控制

   流量控制只能避免【发送方】的数据填满【接受方】的缓存，但不知道网络中发生了什么。拥塞控制就是避免【发送方】的数据填满整个网络。
   拥塞窗口cwnd：发送发维护的一个状态变量，它会根据网络的拥塞程度动态变化。（出现拥塞，cwnd变小）
   如何判断拥塞：发生了超时重传，就是出现了拥塞。
   。。。。那个图拿来吧

   3.3 TCP抓包实战

   Tcpdump + Wireshark 分析网络

   tcpdump 可以抓取指定网口、协议、主机的数据包（例如ping数据包是icmp协议）。它一般只用来抓取数据包，保存抓取的数据包保存成pcap后缀文件。
   用wireshark打开它，能看到数据链路层+IP层+ICMP协议层的详细数据。

   3.4 TCP半连接（SYN）队列和全连接（accept）队列

   TCP三次握手中，服务器收到客户端SYN包，内核会把该连接存储到SYN半连接队列，然后再向客户端发送SYN+ACK包，接着客户端返回ACK，
   服务端收到第三次握手的ACK后，内核会把链接从半连接队列移除，然后创建新的完全链接，将其添加到Accept全连接队列中，等待进程调用accept（）时取出链接。

   TCP全连接队列溢出 （ss命令查看全连接队列）

   接收队列（Recv-Q）、发送队列（Send-Q）不同socket状态含义不同
   Socket-Listen：
   Recv-Q表示：全连接队列长度（已完成三次握手等待服务端accept的连接）。
   Send-Q表示：全连接队列最大长度。
   Socket-Established(非Listen状态)：
   Recv-Q表示：socket缓冲区中还有未被应用程序读取的字节数。
   Send-Q表示：socket缓冲区中还有未被远端主机确认的字节数。
   当超过TCP的最大全连接队列，服务端会丢掉后续进来的TCP连接。丢掉的连接个数可以通过 netstat -s | grep overflowed查看。

   Linux可以修改配置参数 tcp_abort_on_overflow：
   0：全连接队列满了，server直接丢弃client的ack。【默认，提高建立连接的成功率】
   1：全连接队列满了，server发送一个RST包给client，废弃掉这个连接（客户端出现 connection reset by peer）

全连接队列溢出-》项目的问题

一个项目运行久了后就无法和客户端正常建立连接了，使用tcpdump 抓包后发现服务器将客户端握手过程中最后一个ack丢掉了。
使用netstat -s命令查看TCP error相关的信息，发现TCP全连接队列溢出。
使用ss -lnt进一步确认，当前TCP连接队列超过了TCP全连接队列的最大值。

如何增大TCP全连接队列？

它取决于somaxconn 和backlog 之间的最小值。

1. somaxconn 是Linux内核的参数，可以修改。
2. backlog 可以修改配置文件（Nginx）

如果持续不断有连接因为TCP全连接队列溢出被丢弃，应该调大somaxconn 和backlog参数。

TCP半连接队列溢出

并没有专门的命令去看，但能用这条： / $ netstat -natp | grep SYN_RECV | wc -l
模拟它很简单，一致对服务端发送TCP SYN包，不回第三次握手ACK（SYN泛洪、SYN攻击、DDOS攻击）

TCP第一次握手会被丢弃的情况

1. 如果半连接队列满了，并且未开启tcp_syncookies，则会丢弃。
2. 若全连接队列满了，且没有重传SYN+ACK的连接请求多于1个，丢弃。

3. 没开启tcp_syncookies，且max_syn_backlog减去当前半连接队列长度小于2，丢弃

   对抗SYN攻击

4. 增大半连接队列。增大tcp_max_syn_back_log 与全连接队列的大小。

5. 开启tcp_syncookies。（不需要半连接队列。服务器根据当前状态算出一个值，放在SYN+ACK中发出，客户端回复ACK就取出该值校验。合法就认为建立成功。）

6. 减少SYN+ACK的次数。加快SYN_REVC状态的TCP连接断开。

   3.5 TCP内核参数

   TCP三次握手性能提升

7. 客户端-调整SYN报文重传次数 （内网通信，尽快暴漏错误给应用程序）

8. 服务端-调整SYN半连接队列长度
9. 服务端-调整SYN+ACK报文重传次数
10. 服务端-调整accept队列长度

11. 绕过三次握手 （TCP Fast Open,第一次建立连接还是正常的，后续建立连接时，客户端发送的SYN报文会包含数据和cookie，服务端会校验cookie并确认SYN和数据。如果cookie无效，服务器丢弃数据，只确认SYN）【TCP Fast Open需要客户端和服务端同时支持】

    TCP四次挥手性能提升

12. 主动方-调整FIN报文重传次数

13. 主动方-调整FIN_WAIT2状态时间（只适用close函数，不适用shutdown-不受限制）
14. 主动方-调整孤儿连接的上限个数（只适用close函数）
15. 主动方-调整time_wait状态的上限个数

16. 客户端-复用time_wait状态连接

    TCP数据传输性能提升

17. 扩大窗口大小（滑动窗口必须参考带宽时延积）

18. 调整发送缓冲区范围
19. 调整接受缓冲区范围

20. 接受缓冲区动态调节（缓冲区的上限设置为带宽时延积）
    调整内存范围

    四、IP篇

    4.1 IP基础

    数据链路层（MAC）实现了【直连】两个设备的通信。网络层（IP）则是在【没有直连】两个网络之间进行通信传输。
    网络中数据包传输中，源/目标IP地址不变，源/目标MAC地址会变。

    IPV6

    地址为128位，能保证每个设备都有IP地址。
    可自动配置，没有DHCP服务器也可以的。
    包头包首优化（取消了首部校验和等字段），提高了传输的性能。

    IP协议相关技术

    DNS域名解析

    浏览器会去检查自己的缓存，如没有去检查操作系统缓存，还没有去检查本机域名解析文件hosts，还是没有就去查DNS服务器。（只要客户端找到一台DNS服务器，就能通过它找到根域服务器。DNS只会指路，不带路）

    ARP-已知IP去确定MAC地址（ARP请求+ARP响应）

    主机的路由表能找到下一跳的IP地址，可以通过ARP知道下一跳的MAC地址。
    主机会广播发送ARP请求，这个包包含了想知道MAC地址的主机IP地址。
    当整个链路的设备收到ARP请求，会去拆开请求包内容，判断目标IP是否与自己一致，一致则将自己的MAC地址塞入ARP响应包给主机。
    操作系统会缓存MAC地址（会过期）

    RARP协议-已知MAC确定IP地址

    打印机接入网络，RARP服务器返回该机器的IP地址。

    DHCP-动态获取IP地址（全程UDP通信）

21. 客户端发起DHCP发现报文，使用UDP广播通信，目的地址255.255.255.255，DHCP客户端会将IP数据报给链路层，广播到所有设备。【DHCP中继代理可以解决不在同一链路的问题】

22. DHCP服务器用DHCP提供报文响应客户端，报文携带了可租约的IP地址、子网掩码、网关、DNS服务器、IP地址租用期。
23. 客户端收到报文，选择一个DHCP后，发送DHCP请求报文进行响应。
24. 服务端DHCP ACK报文对DHCP请求进行响应。

    NAT-网络地址转换

    同个组织向外通信时，把私有IP地址转换成公有IP地址。
    多个私有IP都转换IP地址为相同的公有地址，只是以不同的端口号区分。（路由器会有个NAPT路由表储存）

    ping原理 - ICMP（Internet Control Message Protocol）

    IP通信中，某个IP包未能到达指定地址，原因将由ICMP负责通知。
    ICMP报文封装在IP包里面，工作在网络层。ICMP类型字段大体分为两类：

• 查询报文类型（用于诊断的查询消息） 回送消息
• 差错报文类型（通知出错原因的错误消息）网络、主机、协议、端口不可达/需要分片但设置了不分片

ping原理就是ICMP协议 【大部分服务器都会屏蔽ICMP，ping可以用来诊断局域网网络情况】

IGMP-英特网组管理协议

常规查询与响应和离开组播组。（组播地址不用于机器IP地址，组播地址没有网络号、主机号。其用于UDP协议，目标地址组播地址，一组的机器都能收到数据包）

4.2 ping的工作原理-ICMP协议大部分服务器都会屏蔽ICMP

ping原理 - ICMP协议 【大部分服务器都会屏蔽ICMP，ping可以用来诊断局域网网络情况】
ICMP（Internet Control Message Protocol）：IP通信中，某个IP包未能到达指定地址，原因将由ICMP负责通知。
ICMP报文封装在IP包里面，工作在网络层。ICMP类型字段大体分为两类：

• 查询报文类型（用于诊断的查询消息-ping） 回送消息。可以对端主机发送回送请求的消息，也可以接受对端主机发回来的回送应答消息。
• 差错报文类型（通知出错原因的错误消息）网络、主机、协议、端口不可达/需要分片但设置了不分片

  ICMP目标不可达类型代码号：

  0 网络不可达
  1 主机不可达
  2 协议不可达
  3 端口不可达
  4 需要进行分片但设置不了分片位

  Ping-ICMP查询报文类型的使用

1. ping命令执行后，源主机会构建一个ICMP回送请求消息数据包【类型1+序号】。每发一个请求都会发出一个请求包，序号+1，报文部分还有发送时间。
2. ICMP协议将数据包连同地址一起交给IP层，IP层将协议字段设置为1表示ICMP协议。
3. 加入MAC头（去本地ARP协议映射表查/ARP协议去查）和其它信息发送出去。

4. 主机B构建ICMP回送响应数据包【类型0+序号】。规定时间内未收到ICMP应答包，认为不可达。

   Traceroute 差错报文类型-接受ICMP超时消息

5. 故意设置特殊的TTL，来追踪来往目的地时沿途经过的路由器。【利用IP包的生存期限，从1开始按照顺序递增的同时发送UDP包，强制接受ICMP超时消息（有的路由器不会返回这个ICMP，有些公网地址看不到经过的路由）】它在发送UDP包时，会填入一个不存在的端口（ 端口不可达），目的主机会返回ICMP消息（端口不可达）。

6. 故意设置不分片，为了路径MTU发现。发送端主机每次收到ICMP差错报文消息时就减少包的大小，定位一个合适的MTU值。

   五、网络综合篇

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

   5.2 Linux系统怎么收发网络包？

   当网卡收到一个数据包后，会通过DMA技术将网络包放入到Ring Buffer中（环形缓冲区）。
   网卡发起硬件中断，中断处理函数处理完需要【暂时屏蔽中断】，然后唤醒【软中断】来轮询处理数据，直到没有数据时才恢复中断（一次中断处理多个网路包）