计算机网络知识总结

一、HTTP

什么是HTTP？超文本传输协议 ,Hyper Text Transfer Protocol
HTTP是计算机世界专门在两点之间传输文字，图片，音频，视频等超文本数据的约定和规范。

1.1、HTTP常见的状态码：

1xx 提示信息，表示目前是协议处理的中间状态，还需要后续操作
2xx 成功，报文已经收到并正确处理；200，204，206
3xx 重定向，资源位置发生变动，需要客户端重新发送请求；301，302，304
4xx 客户端错误，请求报文有误，服务器无法处理；400，403，404
5xx 服务器错误，服务器在处理请求时内部发生错误。500，501，502，503

1.2、HTTP常见字段

Host字段：客户端发送请求时，用来指定服务器域名。Host：www.xxx.com

Content-Length字段：服务器在返回数据时，会有Content-Length字段，表明本次回应的数据长度。
Connection字段：最常用于客户端要求服务器使用 TCP持久链接，以便其他请求复用。Connection字段：keep-alive
Content-Type字段：用于服务器回应时告诉客户端，本次数据是什么格式，
Content-Type: text/html; charset=utf-8：发送的是网页，⽽且编码是UTF-8
Accept 字段：客户端请求的时候，可以使⽤ Accept 字段声明自己可以接受哪些数据格式。Accept: */：客户端声明自己可以接受任何格式的数据。
Content-Encoding字段：说明数据的压缩方法。表明服务器返回的数据使用了什么压缩格式。Content-Encoding: gzip
Accept-Encoding字段：客户端请求时，可以说明自己可以接受哪些压缩方法。Accept-Encoding: gzip, deflate

GET 和 POST?
GET方法是用于向服务器请求获取资源。---安全且幂等
POST方法是用于向URI指定的资源提交数据，数据就在报文的body中。---不安全且不是幂等
安全：在http协议中，指的是请求方法不会破坏服务器上的资源。
幂等：多次执行相同操作，结果都是相同的。

1.3、HTTP特性

优点：

①简单：HTTP基本报文格式就是 header+body，且头部信息也是key-value简单文本形式，易于理解。
②灵活和易于扩展：HTTP协议的各类请求方法，URI/URL，状态码，头字段等每个组成的要求都没有被固定死，都允许开发人员自定义和扩充。
③应用广泛和跨平台。

缺点：
①双刃剑的 无状态：
好处：服务器不会记忆状态，就不需要额外资源，减轻负担。
坏处：因为没有记忆能力，对于一些关联性操作会很麻烦。
解决方法：如Cookie技术。
②双刃剑的 明文传输：好处：就是方便阅读，坏处就是容易被窃取。
③不安全：内容容易被窃听，不验证通信方身份，因此可能遇到伪装（假网站），无法验证报文完整性，所以内容可能被篡改（植入广告）。
HTTP的安全问题可以用HTTPS解决，引入SSL/TLS层。

1.4、HTTPS

(Hyper Text Transfer Protocol over Secure Socket Layer)：
与HTTP区别：HTTP是超文本传输协议，明文传输，存在安全风险问题。①HTTPS则解决了HTTP的不安全问题。在HTTP与TCP之间加入了SSL(Secure Socket Layer)/TLS(Transport Layer Security)安全协议，使得报文能够加密传输。
②HTTP连接简单，在完成TCP三次握手后，就可以进行报文传输。而HTTPS在完成TCP握手后，还需要进行SSL/TLS的握手过程，才能进行加密报文传输。
③HTTP的端口号是80，HTTPS则是443.
④HTTPS协议需要向CA（证书权威机构）申请数字证书，来保证服务器的身份可信。
HTTP的三个风险：窃听，篡改，冒充
HTTPS通过下面三个解决上述风险。
①通过混合加密来实现信息的机密性，解决窃听风险。
在通信建立前采用非对称加密的方式交换会话秘钥，在通信过程中全部使用对称加密的会话秘钥的方式加密明文数据。

②通过摘要算法来实现完整性，解决篡改风险。
客户端在发送明文之前会通过摘要算法算出明⽂的「指纹」，发送的时候把「指纹 + 明文」⼀同加密成密⽂后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明⽂，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。
③通过将服务器公钥放在数字证书中，解决冒充风险。
客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密问后，用自己的私钥解密。

SSL/TLS协议基本流程：
①客户端向服务器索要并验证服务器公钥。
②双方协商产生会话秘钥。
③双方采用会话秘钥进行加密通信。
SSL/TLS的握手阶段(前2步）涉及四次通信：
在此之前，TCP先三次握手建立连接。
1️⃣客户端产生随机数1，将该随机数以及客户端TLS版本号，密码套件列表发送给服务器。
2️⃣服务器收到后，先判断客户端协议版本是否支持，若支持，产生随机数2，并发送该随机数，确定的TLS版本号，使用的密码套件，数字证书给客户端。
3️⃣客户端收到后，先确认服务器的数字证书的真实性，若没有问题，取出服务器公钥，然后用它加密，在向服务器加密发送新产生的随机数3，并且通知加密通信算法改变，表示随后的信息都用「会话秘钥」加密通信。客户端握手结束通知，把之前的所有内容的数据做一个摘要，用来给服务器验证。
4️⃣服务器收到后，通过协商的加密算法，计算出本次通信的会话秘钥，然后向客户端发送加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信，以及服务器握手结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，用来供客户端校验。
⾄此，整个 SSL/TLS 的握⼿阶段全部结束。接下来，客户端与服务器进⼊加密通信，就完全是使用普通的 HTTP协议，只不过用「会话秘钥」加密内容。

1.5、HTTP/1.1的性能

HTTP协议是基于TCP/IP，并且使用了请求-应答的通信模式，影响性能的就是TCP/IP，请求-应答
长连接：早期HTTP/1.0性能上的一个大问题就是，每有一个请求，就需要建立一次TCP连接，增加了通信的开销。为了解决该问题，1.1提出了长连接的通信方式也叫持久连接。 持久连接的特点：只要任意一方没有明确的提出断开连接，则保持TCP连接
管道网络传输：即可以在同一个TCP连接里，客户端发起多个请求，只要第一个发出去了，就不用等待回来，就可以发送第二个，这样就减少了整体的相应时间。但是服务器还是要按照顺序响应，先回应第一个，在响应第二个，如果前面的很慢，后面的请求就排队等待，称为队头阻塞。
队头阻塞 ：如上

1.6、HTTP/1.1的优缺点

①改进：长连接改善了HTTP/1.0短连接的性能开销；管道传输减少了整体的响应时间。
②存在缺点：请求/响应头部没有压缩，首部信息越多，延迟越大；首部冗余，造成浪费；服务器按请求顺序响应，会出现队头阻塞；没有请求优先级控制；请求只能来自客户端，服务器只能被动相应。

1.7、HTTP/1.1如何优化？

①长连接，减少了tcp连接和断开的次数，减少网络传输的延迟，提高了传输效率。
②尽量避免发送HTTP请求，对于每次请求得到的数据都一样的，我们可以把请求的数据缓存在本地，下次直接本地读取更快。故可以采用缓存技术，将请求的URL作为key，响应作为value。万一缓存不是最新的呢？服务器发生响应时，会估计一个过期时间，放在响应的头部，客户端通过查看缓存中响应的该信息来判断。但是也可能缓存的时间过期了，但是服务器上的资源并没有更新呢？只需要在客户端向服务器发送请求时，在请求的头部带上缓存中响应头部的摘要，服务器收到后，比较自己的摘要和收到的摘要，若不相同了，则返回服务器上的新资源，若相同，则仅返回304 not modified响应，减少了数据量。
③减少HTTP的请求次数，
1、减少重定向请求次数，有时候因为迁移，维护等原因，资源发生了移动，但客户端不知道，一般做法，客户端请求旧的的URL，服务器收到后，会返回302（重定向）以及新的url，客户端收到后，在请求新的url。同时服务器也往往不知一级，重定向越多，客户端就需要更多请求。故可以将重定向工作交给代理服务器完成，就可以减少请求次数。即一个代理服务器收到某个url后，发现它已经被重定向，则直接去使用新的url先上级请求数据即可，而不是返回给下级，让客户端重新发起请求。
④合并请求，将访问多个小文件的请求合并为一个大的请求，减少了重复发送头部，同时可以阻止单个请求阻塞。合并请求的几种形式：1、有的网页会含有很多小图片，小图标，有多少个小图片，客户端就要发起多少次请求。那么对于这些小图片，我们可以考虑使⽤ CSS Image Sprites 技术把它们合成⼀个⼤图⽚，这样浏览器就可以⽤⼀次请求获得⼀个大图⽚，然后再根据 CSS 数据把⼤图片切割成多张小图⽚。但是带来的问题就是，当大资源的某一个小资源发生变化时，客户端就必须重新下载整个大资源文件。
⑤延迟发送请求：按需获取，来减少第一时间的请求总数。
⑥减少响应数据：压缩（无损压缩，有损压缩）

1.8、HTTPS如何优化？

①秘钥交换算法：RSA是传统的秘钥交换算法，但不具备前向安全性，并且只有在四次握手完成后才能进行数据传输；ECDHE具有前向安全性，并且客户端可以不等服务器的最后一次TLS握手，就可以提前发出加密的HTTP数据，节省了一个消息的往返时间。ECDHE算法是基于椭圆曲线实现的，不同椭圆曲线性能也是不同的，尽量选择X25519曲线。
②TLS升级：TLS1.3完成TLS握手只需要1RTT，安全性更高。
TLS1.3的握手过程：1、客户端在client hello消息里带上支持的椭圆曲线以及椭圆曲线对应的公钥。2、服务端收到后，选择一个椭圆曲线等参数，然后返回消息时，带上服务端的公钥。经过这一个RTT，双方手上已经有生成会话秘钥的材料了，于是客户端计算出秘钥，就可以进行数据的加密运输了。
③证书优化：1、证书传输优化，服务器的证书尽量选择ECDSA（椭圆双曲线）证书，而不是RSA证书，因为相同的安全强度下，前者的秘钥长度短，更便于传输。2、证书验证优化：客户端验证证书时，会走证书链逐级验证，不仅需要用CA公钥解密证书和用签名算法验证证书的完整性，而且为了知道证书是否被CA吊销，还要去访问CA，这个过程是HTTP访问，会产生一系列开销，现在基本都使用OCSP（在线证书状态协议online certificate status protocol）来查询证书的有效性，工作方式为向CA发送查询请求，让CA返回证书的有效状态。
④会话复用：会话复用分为两种
1、Session ID：工作原理是客户端和服务器首次TLS握手连接后，双方会在内存缓存会话秘钥，并用唯一的Session ID来标识，当客户端在此连接时，hello消息会带上Session ID ，服务器收到后会在内存找，如果可以找到就直接用该会话秘钥恢复会话状态，同时为了安全，内存中的会话秘钥会定期失效。缺点：Ⅰ、服务器必须保持每一个客户端的会话秘钥，随着客户端的增加，内存压力也会变大。Ⅱ、现在网站服务一般都是有多台服务器通过负载均衡提供服务，客户端在此连接的不一定会命中上次访问的服务器，这种就还是要完整的TLS握手。
2、Session Ticket：可以解决上述问题，服务器不再缓存每个客户端的会话秘钥，而是缓存在客户端。客户端与服务器首次连接时，服务器会加密会话秘钥作为ticket发给客户端，客户端缓存该ticket（本次的会话秘钥肯定也要缓存起来），客户端再次连接服务器时，客户端发送该ticket，服务器解密后就可以获取上次的会话秘钥，验证有效期，如果没问题，就恢复通信。对于集群服务器，要确保每台服务器加密会话秘钥的秘钥一致，这样客户端携带ticket访问任意一台服务器时，都可以恢复会话。
总结：这两种方式都不具备前向安全性，同时不能应对重放攻击。
TLS1.3支持的Pre-shared Key,重连只需要0RTT，原理类似于2，只不过将Ticket和HTTP请求一并发给服务端。也存在重放攻击风险。
应对重放攻击的方法：给会话秘钥设定一个合理的过期时间，以及只针对安全的HTTP请求如GET/HEAD使用会话复用。

1.9、HTTP/2

首先了解一下HTTP/1.1协议存在问题：
现在网络环境下：
*数据变大了；页面资源变多了；内容形式丰富了；实时性要求高了；
这些变化带来的最大问题就是HTTP/1.1的高延迟。尽管在前面已经讲过怎么优化HTTP/1.1，但都没有伤筋动骨，没有从根本上解决问题。
HTTP/2就是从根本上去解决1.1中存在的问题。
①HTTP/2首先兼容1.1，故容易推广。
②头部压缩：1.1协议只压缩了后面的数据，头部并没有进行压缩。1.1中头部存在的问题：1.含有很多固定字段，所以有必要压缩；2.大量的请求/响应报文中很多是重复的，可以避免重复性；3.字段是ASCII编码，效率低，可以改为二进制编码。
HTTP/2开发了HPACK算法（静态字典，动态字典，huffman编码），客户端和服务器都建立和维护字典，用长度较小的索引号来表示重复的字符串，再用huffman编码压缩数据。
静态表编码：HTTP/2为高频出现在头部的字符串和字段建立了一张静态表，将它写入HTTP/2框架里，不会变化的。
动态表编码：将静态表中包含以外的头部字符串自行构建动态表，如第一次发生头部中的某一个低频的头部字符串，经过hffman编码发送出去，客户端和服务端都更新自己的动态表。下次发送时直接发送动态表索引即可。服务器收到索引后，直接去动态表查找即可。但动态表生效的前提是必须在一个连接上，重复传输完全相同的HTTP头部。但缺点是，动态表越大，占用的内存也就越大。
二进制帧：极大的提高了HTTP的传输效率，并且二进制解析更高效。HTTP/2将响应报文划分为两个帧（HEADERS,DATA这是帧类型），也就是将一条HTTP响应划分为两个帧来传输，并且采用二进制编码。

如上图所示，帧头只有9个字节，前3个字节表示帧数据的长度。第4个字节表示帧类型（一共两种大类型，10个,如下图），第5个字节是标志位，可以保存8个标志位，用于简单的控制信息（如头数据的结束标志，单方向的数据发送完毕，流的优先级），帧头的最后4个字节是流标识符，高位保留不用，共31位（2^31），作用是用来标识该frame属于哪个stream，接受方可以根据这个信息从收到的乱序的帧中找到相同的stream id的帧，有序组装信息。最后就是帧数据，它存放经过hpack算法压缩过的HTTP头部和包体

并发处理：HTTP/1.1是基于请求-响应模型的，同一个连接中，HTTP完成一个事务，才能处理下一个，即存在队头阻塞。而HTTP/2可以多个stream复用一个tcp连接，达到并发的效果。在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，⽽同⼀ Stream 内部的帧必须是严格有序的。客户端和服务器双⽅都可以建⽴ Stream， Stream ID 也是有区别的，客户端建⽴的 Stream 必须是奇数号，⽽服务器建⽴的 Stream 必须是偶数号。同⼀个连接中的 Stream ID 是不能复⽤的，只能顺序递增，所以当 Stream ID 耗尽时，需要发⼀个控制帧GOAWAY ，用来关闭 TCP 连接。HTTP/2 还可以对每个 Stream 设置不同优先级，帧头中的「标志位」可以设置优先级，比如客户端访问HTML/CSS 和图片资源时，希望服务器先传递 HTML/CSS，再传图片，那么就可以通过设置 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 队头阻塞问题。

1.10、HTTP/2的优缺点

①改进：1、头部压缩，即HPACK算法，提高了速度；二进制传输，增加了传输效率；2、数据流，数据包可以不按照顺序发送。每个请求或响应的所有数据包称为一个数据流，每个数据流有独一无二的编号，规定客户端发出的数据流编号为奇数，服务器发出的数据流为偶数。同时客户端可以指定数据流的优先级，优先级越高，服务器优先响应；3、多路复用，在一个连接中可以并发多个请求或回应，而不用按照顺序一一对应；4、服务器推送，在客户端发起请求时，服务端就会把可能用到的资源发送给客户端，减少延时等待。
②存在缺点：多个HTTP请求复用一个TCP连接时，下层TCP协议不知道有多少个HTTP请求。一旦发生丢包，就会触发TCP重传机制，所有的HTTP请求都必须等待该包被重传回来。

1.11、HTTP/3

虽然HTTP/2已经大幅度提升了性能，但是由于HTTP/2是基于TCP实现的，存在以下三个缺陷：
①队头阻塞；因为 TCP 是字节流协议，TCP 层必须保证收到的字节数据完整且有序的，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从HTTP 视角看，就是请求被阻塞了。
②TCP和TLS的握手延时；发起 HTTP 请求时，需要经过 TCP 三次握手和TLS 四次握手（TLS 1.2）的过程，因此共需要 3 个 RTT 的时延才能发出请求数据。另外， TCP 由于具有「拥塞控制」的特性，所以刚建⽴连接的 TCP 会有个「慢启动」的过程，它会对 TCP 连接产⽣"减速"效果。
③网络迁移需要重新连接；⼀个 TCP 连接是由四元组（源 IP 地址，源端口，目标 IP 地址，目标端口）确定的，这意味着如果 IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握⼿，这不利于移动设备切换网络的景，比如 4G网络环境切换成WIFI。
上述问题都是TCP协议固有的问题，因此HTTP/3使用UDP了。

UDP(Quick UDP Internet Connection)是一个不需要连接的不可靠的传输协议，因此它比TCP快，而且UDP包是无序的，也没有依赖关系。但是如果仅仅将传输协议换成UDP，肯定是不行的（数据的不可靠传输），所以还基于UDP协议在应用层实现了QUIC协议，它具有类似TCP的连接管理，拥塞窗口，流量控制的网络特性，将不可靠的UDP协议变成可靠的了。
QUIC协议的优点：
①无队头阻塞；UDP包没有依赖关系，但是为了数据包的可靠性，QUIC协议会给每个数据包一个序号，当某个流的一个数据包丢失后，即使该流的其他数据到了。HTTP/3也无法读取，直到QUIC重传丢失的报文，数据才会交付。但是其他流的数据包只要被完整接受，HTTP/3就可以读取到数据。
②更快的连接；对于原来的HTTP协议，TLS和TCP在不同层，故很难将他们合并在一起，需要分步。但是HTTP/3的QUIC协议和TLS协议是在一层的，QUIC协议内部包含了TLS（实际使用TLS1.3），因此可以合并在一起，只需要一个RTT就可以同时建立好连接和秘钥协商，在第二次连接时，只需要0 RTT即可。
③连接迁移；以前，我们是通过四元组（源IP，源端口，目的IP，目的端口）确定一条TCP连接的，当设备网络从4G切换到WIFI时，IP变化了，就必须重新建立连接（包含了三次握手，TLS的四次握手，TCP慢启动的影响），所以迁移成本很高。而QUIC通过连接ID来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使IP变化了，只要保存了上下文（连接ID,TLS秘钥等），就可以无缝复用原来的连接。

二、TCP

2.1、TCP 基本知识

TCP 头部：

序列号：在建立连接是有计算机生成的随机数作为初始值，通过SYN包发送给接收端，每发送一次数据，就累加一次数据的大小。用于解决网络包乱序问题。
确认应答号：指下一次期望收到的数据序列号，发送端收到这个确认应答后可以认为该序号以前的数据都已经正常接收了，用于解决不丢包的问题。
ACK:该位为1是，‘确认应答’的字段有效，TCP规定除了最初建立连接时SYN包之外该位必须为1；
RST：该位为1时，表示TCP连接中出现异常必须强制断开连接
SYN：该位为1时，表示希望建立连接，并在其‘序列号’的字段进行初始化设置；
FIN：该位为1时，表示今后不会在有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换FIN位为1的TCP段；

什么是TCP？
TCP是面向连接的（一对一的），可靠的，基于字节流的传输层通信协议

为什么需要TCP协议？
TCP是一个工作在传输层的可靠数据传输的服务，能保证接收端收到的网络包是无损坏，无间隔，非冗余和按序的。

什么是TCP连接？
⽤于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket（IP地址和端口号组成）、序列号（解决乱序）和窗⼝大小（流量控制）称为连接。

2.2、UDP

UDP头部：

目标和源端口：主要是告诉 UDP 协议应该把报⽂发给哪个进程。
包长度：该字段保存了 UDP 首部的长度跟数据的长度之和。
校验和：校验和是为了提供可靠的 UDP 首部和数据而设计。

TCP和UDP的区别？
1、连接：
TCP是面向连接的传输层协议，传输数据前需要先建立连接。
UDP是不需要连接的，即刻传输数据的。
2、服务对象：
TCP是一对一的两点服务。
UDP支持一对一，一对多，多对多通信。
3、可靠性：
TCP是可靠交付数据的，数据无差错，不丢失，不重复，按需到达。
UDP是尽最大努力交付数据，不保证可靠交付。
4、拥塞控制、流量控制
TCP有拥塞控制和流量控制机制
UDP没有，即使网络拥堵了，也不影响发送速率。
5、首部开销：
TCP首部长度较长，会有一定开销。
UDP首部只有8字节，固定不变，开销较小。
6、传输方式：
TCP是流式传输，没有边界，但保证顺序和可靠。
UDP是一个一个包发送，是有边界的，但可能丢包或乱序。
7，分片不同：
TCP的数据大小如果大于MSS，则会在传输层进行分片，目标主机收到后，在传输层会组装TCP数据包，如果中途丢失某一个分片，只需要传输该分片即可。
UDP的数据大小如果大于MTU大小，则会在IP层进行分片，目标主机收到后，会在IP层组装数据，在交付给 传输层，但是中途丢了一个分片，在实现可靠传输的UDP是则需要重传所有的数据包，这样的传输效率就非常差，所以通常UDP报文应该小于MTU。

TCP和UDP应用场景
TCP应用于：FTP文件传输、HTTP/HTTPS
UDP应用于：包总量较少的通信如DNS,SNMP等、视频、音频、广播通信。

2.3、TCP连接建立-三次握手

1️⃣服务端主动监听某个端口，处于LISTEN状态；2️⃣客户端发起TCP连接，随机初始化序列号并填入TCP报文的首部序列号中，并将控制位SYN置为1，表示SYN报文，将该报文发送给服务端，然后客户端处于SYN-SENT状态；3️⃣服务端收到客户端的SYN报文后，也初始化自己的序号，并填入TCP首部的序列号段中，其次将确认应答号改为收到的客户端序列号加1，并将SYN置1和ACK值1，在发送给客户端，之后服务端处于SYN-RCVD状态。4️⃣客户端收到服务端报文后，还需要给服务端一个应答报文（用于同步服务端的序号），首先将ACK置1，确认应答号填入收到的服务端序列号+1，序列号在上次基础上+1，这次可以携带数据，之后客户端处于ESTABLISHED状态。5️⃣，服务端收到后，也将状态改为ESTABLISHED状态。

2.3.1、为什么是三次握手

首先TCP连接是用于保证可靠性和流量控制维护的某些状态信息，所以为什么三次握手可以初始化这些状态信息？
三次握手的原因：
1、三次握手可以阻止重复历史连接的初始化；
假设，服务端某次的序列号是9的SYN报文，因为某些原因在网络中延迟了，客户端半天没有收到服务端的应答，就又发送了一个序列号为12的SYN报文，但是假设这时候前一个SYN报文先到达了服务端，则应答报文里面的确认应答号就是10，客户端收到后比较一下，就知道现在需要的应该是13，所以发起RST报文中止连接。等待序列号12的SYN报文到达服务端，服务端给客户端一个确认应答号为13的报文，客户端就会正常响应。
若是两次握手，就不能判断当前连接是不是历史连接了（因为两次握手的话，服务端收到SYN报文，在给客户端一个应答，就建立连接了。）三次的时候，若是历史连接，就发送RST报文，终止连接，若不是，就发送ACK报文。
2、三次握手可以同步双方的初始序列号；
因为一方产生初始化序列号的SYN报文，也需要另一方产生ACK应答报文，故一来一回需要三次握手。序列号的作用：接受方可以去除重复的数据；可以根据数据包的序列号按序接受；可以标识发送出去的数据包，哪些是被对方接收到的；两次握手只能同步其中一方的序列号；四次握手也可以同步初始化序列号，只不过将服务端的ACK和SYN一起发送出来就是三次握手了。
3、三次握手可以避免资源浪费。
如果是两次握手，当客户端的SYN报文在网络中堵塞时，会重复发送SYN；由于没有第三次握手，服务端每次收到SYN就会先建立连接。那么就会建立多个冗余的连接，造成浪费。三次握手时，会在第三次握手，服务端才会建立连接，而对于前面冗余的情况，在第二次握手时，客户端会发起RST报文中止连接。

为什么客户端和服务端的初始序列号是不一样的？
如果一个失效的连接被复用，但是就连接的历史报文还残留在网络中，如果序列号相同，那么就无法分辨出该报文是不是历史报文。所以每次连接前重新初始化序列号是为了让通信双方能够根据序列号将不属于本次连接的报文段丢弃。也增加安全性，防止第三者伪造序列号接收报文。

既然IP层会分片，为什么TCP层还要MSS呢？

MTU：一个网络包的最大长度，以太网一般为1500字节；
MSS：除去IP,TCP头部之后的一个网络包所能携带的TCP数据的最大长度。

当我们不考虑TCP的报文大小，一股脑交给IP层，IP层会将大小超过MTU的进行分片发送，目标主机收到后在IP层组装交给传输层。但如果中间如果有某一个分片丢失，因为IP层本身没有超时重传机制，则传输层发现数据不完整，就不会发送ACK给对方，则会触发超时重传，即需要重新发送整个TCP报文。因此在IP层进行分片传输是非常没有效率的事情。
为了达到最佳的传输效率，在TCP协议建立时协商双方的MSS，当TCP层的数据小于MSS时，到达IP层，也就不会大于MTU，ip层就不需要分片传输了。即使本次报文丢失，进行重发时也是以MSS为单位，而不用重传所有分片。

2.3.2、什么是SYN攻击？如何避免？

通俗说，攻击者短时间伪造不同的IP地址，不断给被攻击的服务器发送SYN报文，该服务端收到后，会回一个SYN+ACK报文，并且进入SYN_RCVD状态，但攻击者并不响应，久而久之，服务端的SYN接受队列（未连接队列）就会满，就不会响应正常用户的TCP连接请求了。

正常流程：
1、服务端收到客户端的SYN报文，会将其加入SYN队列；
2、发送ACK+SYN给客户端，等待客户端的ACK报文；
3、服务端收到ACK报文后，从SYN队列移除放到Accept队列；
4、应用通过调用accept()socket接口，从Accept取出连接；

SYN攻击下：SYN队列会占满；

避免SYN攻击的方法：

1、当SYN队列满后，后续的SYN不会在进入SYN队列；
2、计算出一个cookie值，再以SYN+ACK中的序列号返回给客户端；
3、服务端收到客户端的应答报文时，服务器会检查这个ACK包的合法性，如果合法，就直接放到Accept队列；
4、应用通过调用accept() socket接口，从Accept队里中取出连接。
注：因为SYN攻击者是不会发送ACK报文的，而正常的客户端时会发送ACK的，故以cookie这种形式发送给客户端，只有正常的才会响应，故对收到的ACK，验证其合法性即可，这样就将攻击者和正常用户区分出来了。

2.4、TCP断开连接-四次挥手

整个流程如上图：
1️⃣通信双方中的一方，想要发起TCP关闭连接请求的发起方会发送FIN报文给另一方，之后发起方会进入FIN_WAIT_1状态；
2️⃣被发起方收到FIN报文，就会给发起方发送ACK报文，进入CLOSED_WAIT状态；
3️⃣被发起方处理完数据后，会向发起方发送FIN报文，进入LAST_ACK状态；
4️⃣发起方收到该FIN报文，随即回一个ACK报文，之后进入TIME_WAIT状态；
5️⃣被发起方收到该ACK报文，就进入CLOSED状态，至此被发起方已经完成连接的关闭；
6️⃣发起方经过2MSL时间后，自动进入CLOSED状态，至此发起方完成连接的关闭；
注：发起方才会有TIME_WAIT状态，并且后完成连接的关闭。

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

MSL：Maximum Segment Lifetime （报文最大生存时间）,即任何报文在网络中存在超过这个时间，就会被丢弃。（TCP协议基于IP协议，IP协议中有一个TTL字段，是IP数据包可以经过的最大路有数，每经过一个，就会减一，此值为0，就会丢弃该数据报，同时发送ICMP报文通知源主机）；MSL单位是时间，TTL是数目，所以MSL应该大于等于TTL=0所需时间，以确保报文已经消亡。
解释：因为网络中存在往来的数据报，当发送方发送的数据包被接收方收到并发送响应报文，一来一回需要2倍时间。当第四次握手的ACK报文在网络中丢失时，被发起方就会收不到该报文，就会触发超时重传，重新发送FIN报文，发起方收到后，会重发ACK报文（这样的极限时间就需要2 MSL），并重新计时2 MSL。

2.4.2、为什么需要TIME_WAIT状态？

①防止具有相同四元组的旧数据被接收；
当TIME_WAIT没有等待时间或者时间过短，且正常关闭（即第四次挥手的ACK报文正常接收）。则相同端口的 TCP被复用后，可能上一次连接中被延迟的报文就会抵达某一端，那么就有可能被正常接收这个过期报文，就会产生数据错乱。所以，TCP 就设计出了这么⼀个机制，经过 2MSL 这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都⾃然消失，再出现的数据包⼀定都是新建立连接所产⽣的。

②保证被动关闭的一方可以被正确的关闭，即保证第四次握手的ACK被正常接收。
当TIME_WAIT没有等待时间或者时间过短，第四次挥手的报文丢失，则主动发起方因为TIME_WAIT时间到啦了，就关闭了，被发起方由于没有收到第四次的应答报文，则一直处于LAST_ACK状态，若收到新的SYN请求报文，则会发送RST报文拒绝连接。

2.4.3、TIME_WAIT过多有什么危害？

1、内存资源占用；
2、对端口资源的占用，一个TCP连接至少消耗一个本地端口；
如果发起连接的一方的TIME_WAIT 状态过多，占满了所有端口资源，则会导致无法创建新连接。
客户端受端口资源限制：客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占完就无法创建新的连接；
服务端受系统资源限制： 理论上服务端可以建立很多连接，服务器只监听一个端口但是会把连接扔给处理线程，所以理论上监听的端口可以继续监听，但是线程池处理不了那么多不断的连接，当服务端出现大量TIME_WAIT时，系统资源被占满时，会导致处理不过来新的连接。

2.5、MTU分片和MSS分片的区别？

如果⼀个大的 TCP 报文是被 MTU 分片，那么只有「第⼀个分片」才具有 TCP 头部，后面的分片则没有 TCP头部，接收方在 IP 层只有重组了这些分片，才会认为是⼀个 TCP 报⽂，那么丢失了其中⼀个分片，接收方 IP 层就不会把 TCP 报文丢给 TCP 层，那么就会等待对⽅超时重传这⼀整个 TCP报文。
如果⼀个大的 TCP 报⽂被 MSS 分片，那么所有「分片都具有 TCP 部」，因为每个 MSS 分片都是具有TCP 头部的TCP报⽂，那么其中⼀个 MSS 分片丢失，就只需要重传这⼀个分片就可以。

2.6、重传机制

若在数据传输中，发生了数据丢失，会使用重传机制解决。
重传机制：超时重传、快速重传、SACK、D-SACK

2.6.1、超时重传

在发送数据时，设置一个定时器，当超过指定时间还没有收到对方ACK确认应答报文，就会触发超时重传，重新发送该数据。
会引起超时重传的两种情况：
1、数据包丢失
2、确认应答丢失

当超时时间RTO较大时，重发就很慢，数据已经丢失半天了，才会重发，效率低；
当超时时间RTO较小时，会导致数据可能没有丢就重发了，会增加网络拥塞，导致更多的超时。
故超时时间RTO应该略大于RTT
但实际网络中RTT是一个变化的值。
当超时重发的数据又超时时，将会把时间间隔提升为原来的两倍。因为再次超时，说明网络不行，不适合频繁发送。

2.6.2、快速重传

不以时间为驱动，而是以数据驱动重传。

在上图，发送⽅发出了 1，2，3，4，5 份数据：
第⼀份 Seq1 先送到了，于是就 Ack 回 2；
结果 Seq2 因为某些原因没收到，Seq3 到达了，于是还是 Ack 回 2；
后面的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；
发送端收到了三个 Ack = 2 的确认，知道了 Seq2 还没有收到，就会在定时器过期之前，重传丢失的 Seq2。
最后，收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6 。
快速重传的问题：重传时，是重传之前的一个，还是重传所有，上图是重传之前的一个。但是实际中都有可能。故衍生出SACK方法。

2.6.3、SACK

（选择性确认）Selective Acknowledge
在TCP头部的选项字段中添加一个SACK，它可以将缓存的地图发送给发送方，这样发送方就知道哪些数据收到了，哪些没有收到。

如上图，发送方收到三次同样的ACK确认报文，就会触发重传，通过SACK信息发现200-299的数据就是，则重传时，就选择这个TCP段进行重传即可。

2.6.4、D-SACK

Duplicate-SACK 主要使用SACK告诉发送方有哪些数据重复接收了。
情况1：ACK确认应答丢失。

情况2：网络延迟。

总之，D-SACK的好处如下：
1、可以让发送方知道，是发出去的包丢失了，还是接收方的ACK丢失了；
2、可以知道是不是发送方的数据包被网络延时了；
3、可以知道网络是不是把发送方的数据包给复制了；

2.7、滑动窗口

在前面，TCP都是每发送一个数据包，都需要进行一次确认应答。当上一个数据包收到了应答，才会在发送下一个。这种方式效率太低了。
缺点在于：数据包往返时间太长，通信效率低。

为了解决上述缺点，TCP引入了窗口。
窗口大小：指的是无需等待确认应答，而可以继续发送数据的最大值。
窗口的实际实现：操作系统开辟一个缓存空间，发送方在收到确认应答前，必须在缓存区保留已经发送的数据，若收到确认应答，则从缓存区清除。

上图的窗口大小为3，虽然在传输过程中，ACK 600丢失了（但是数据是传输到了接收方），发送方接受不到600的ACK，但是收到了700的 ACK,说明700以前的都收到了，故不用重发500-599之间的数据。这种模式叫累计确认（累计应答）。
窗口大小的确认？
TCP头里面有一个字段windows，这个字段可以告诉发送方自己还有多少缓存区来接受数据。发送者收到这个信息后，就根据此信息来确定需要发送数据的大小。因此窗口的大小由接收方的窗口大小来决定的。

2.7.1、发送方的滑动窗口：

如上图，窗口大小为20+6 = 26.可用窗口大小为6.在程序中，TCP的滑动窗口由两个绝对指针，一个相对指针来跟踪。
SND.WND:表示发送窗口大小；
SND.UNA：表示依法偶是那个但是没确认的第一个字节序列号。是一个绝对指针。
SND.NXT：指向未发送但可发送范围的第一个字节的序列号，也是夜歌绝对指针。
指向#4的第一个字节的是一个相对指针，SND.UNA+SND.WWND;
可用窗口大小 = SND.WND-(SND.NXT-SND.UNA);

2.7.2、接收方的滑动窗口

如上图，接受窗口大小为20.
RCV.WND: 表示接受窗口的大小。
RCV.NE\XT：指向期望从发送者发送过来的下一个字节的序列号，是一个指针。
指向#4第一个字节的是一个相对指针，需要RCV.NXT+RCV.WND

从上面可以看出接受窗口大小和发哦是那个窗口大小是不一定相等的。
因为接收方接受到数据后，是给上层使用的，如果上层读取数据非常快，那么接受窗口很快就空缺出来了，在通过TCP报文告诉给发送者。那么这个传输过程是存在延时的，所以发送窗口和接收窗口是约等于的关系，并不是严格相等的。

2.8、流量控制

发送方不能无脑的发送数据给接收方，要考虑接受方的处理能力。为了解决这个现象的发生，TCP提供一种机制可以让发送方根据接受方的实际接收能力控制发送数据量，称为流量控制。


当可用窗口变为0时，发送方实际会定时发送窗口探测报文，以便知道接受方的窗口大小是否发生变化。

情况:

如上图，会出现数据丢失的现象，实际上为了防止这样的情况，TCP规定不允许同时减小缓存又收缩窗口，而是先收缩窗口，过段时间在减小缓存，就可以避免丢包情况。

2.8.1、窗口关闭的风险

若某次发送方的可用窗口为0了，正常流程等待接收方处理完数据，会给发送方发送窗口非0的报文，发送方接收到该报文后，会继续发送数据。但是若该报文丢失了，对接收方而言，会一直等待发送方发送数据，对发送方而言，一直在等待窗口改变的通知，双方就一直这样僵持下去了吗？
但实际上，TCP为每个连接提供一个定时器，只要一方的窗口为0，就会启动该窗口，隔一定时间会发送窗口探测报文，对方收到这个探测报文，会发送自己的窗口大小。

2.8.2、糊涂窗口

如果接收方太忙了，来不及取出窗口里的数据，就会使得发送方的发送窗口越来越小，到最后，如果接受方有几个字节的大小的窗口并告诉发送方现在的窗口大小，则发送方就会发送这几个字节大小的数据。这时候就有点高射炮打蚊子，因为一个tcp的头字节都几十，但数据才几个字节，就太浪费了。
糊涂窗口的现象：
1、接收方通知一个小窗口；
2、发送方发送一个小数据；
解决方法：
对接收方而言，当窗口大小小于min(MSS,缓存空间/2),就通知一个0，阻止发送方发送数据。
对发送方而言，…

2.9、拥塞控制

相比之下，流量控制是避免发送方的数据填满接收方的缓存，和网络情况是没有关系的。拥塞控制就是为了避免发送方的数据填满整个网络。当网络不好时，如果一直发送数据，就一直收不到，一直重传，网络问题就更加严重。

2.9.1、拥塞窗口

是发送方需要维护的一个状态变量，根据网络状况实时动态变化的。
在前面的流量控制中，发送窗口和接收窗口是约等于的关系，但是在考虑拥塞窗口后，发送窗口的大小=min（原发送窗口大小，拥塞窗口大小）。
拥塞窗口大小变化的规则：只要网络中没有出现拥塞，就增大，出现拥塞，就减小。

什么时候发生拥塞？发生重传的时候。

拥塞控制的四种算法：

2.9.1.1、慢启动

TCP刚建立完成后，首先是一个慢启动过程，即一点一点提高数据量。每当收到一个新的ACK，拥塞窗口大小就增加收到ACK的总和个（即翻倍）即呈指数增长。但肯定有一个限制，即慢启动门限ssthresh，拥塞窗口大小小于慢启动门限，就使用慢启动，否则就会使用拥塞避免算法。下图初始化的cwnd=1，收到第一个ack，拥塞窗口大小变成2，在收到第二个，拥塞窗口大小就是4，。。。

2.9.2.2、拥塞避免

当拥塞窗口大小大于等于慢启动门限时，使用拥塞避免算法。
拥塞避免算法的规则是，每收到一个新的ACK，拥塞窗口就增加1（线性增长）。

2.9.2.3、拥塞发生

当触发重传机制时，就进入拥塞发生算法。
重传机制主要有两种：超时重传，快速重传，在不同的重传下，拥塞发生算法也不一样。
①超时重传下的拥塞发生算法：
将慢启动门限更新为当前拥塞窗口的一半；拥塞窗口重置为1.重传数据，当再次受到ACK时，正常执行慢启动算法或者拥塞避免算法。

看上图也可以发现，窗口大小来了个急刹车，是不好的。
②发生快速重传时的拥塞发生算法
先将拥塞窗口大小变为原来一半，慢启动门限置为当前的拥塞窗口的大小。然后进入快速恢复算法（如下）。

2.9.2.4、快速恢复

快速恢复算法和快速重传算法一般是同时使用的。
快速恢复算法认为，你还可以收到3个重复的ACK，说明网络并不是很差，所以不需要像超时重传那样，直接将窗口大小重置为1.
进入快速恢复前：
拥塞窗口大小变为原来的一半；慢启动门限也变为现在的拥塞窗口大小；
进入快速恢复算法：
拥塞窗口 = 慢启动门限+3（收到了三个重复的ACK）；
重传丢失的数据包；
如果继续收到重复的ACK，那么拥塞窗口增加1；如果继续收到的是新数据的ACK，则将拥塞窗口大小置为慢启动门限，随后转入拥塞避免算法。

三、IP

首先 IP在处于网络层，网络层的主要作用是实现主机与主机之间的通信，即点对点的通信。
网络层和数据链路层的区别：网络层只考虑点到点，而链路层是两点之间直连设备之间的通信。

在数据传输过程中，只有源mac地址和目标mac地址一直在变化，而源ip地址和目标ip地址是不会变化的。
IP地址（IPv4）由32位二进制来表示，IP地址在计算机是以二进制方式处理的，但为了方便记忆，采用点分十进制的标记方式，将32位按8位一组分成4组，每组用十进制表示，用.号划分每组。

实际上，IP地址不是以主机来配置的，而是以网卡。服务器，路由器等都有两个以上的网卡，就会有多个IP地址。

3.1、IP地址分类：

5大类：

网络号与主机号的划分： a.b.c.d/x x表示前x位属于网络号。

最大主机数计算，2的主机号位数-2；减2的原因：因为主机号全为1，全为0的比较特殊。主机号全为1指定某个网络下的所有主机，用于广播；主机号全为0指定某个网络。
广播地址用于在同一个链路中相互连接的主机之间发送数据包。
分为本地广播和直接广播
在本网络号内广播叫本地广播。如网络地址是192.168.0.0/24时，广播地址为192.168.0.255/24 。因为这个广播地址的IP包会被路由器屏蔽，所以只能在本网络号内传输。
在不同网络间的广播叫直接广播。如网络号为192.168.0.0/0的主机向192.168.1.255/24的目标地址发送IP包，收到这个包的路由器，将数据发送给192.168.1.0/24下的所有主机。

D,E类没有主机号，所以不可用于主机IP，D类常被用在多播，E类是预留的分类，暂时不使用。

多播有什么用？
因为广播无法穿透路由，若想实现给1其他网段发送同样的包，就可以使用可以穿透路由的多播。

IP分类的优点：
当路由器或者主机得到一个IP地址，首先根据第一位是不是0，是0就是A类地址，在判断第二位是不是0，是0就是B类地址，以此类推。
IP分类的缺点：
同一网络没有地址层次，即无法在继续划分；不能很好的与现实网络匹配，C类地址包含的主机数太少了，B类包含的主机数又太多了。
可以通过CIDR无分类地址解决。

3.2、无分类地址CIDR

怎么划分网络号和主机号呢？a.b.c.d/x 其中x表示前x位属于网络号。

子网掩码也可以用来划分主机号和网络号，将子网掩码与IP地址按位与的结果就是网络号。

为什么要分离网络号和主机号？
因为两台计算机要通信，首先判断是否处于同一个广播域内，即网络地址是否相同。若相同，则表明接收方在本网络上，可以直接发生数据包给目标主机；路由器寻址工作中，也是通过这样的方式来找到对应的网络号的，进而把数据包转发到对应的网络内。
怎么进行子网划分？
使用子网掩码。子网划分实际上是将主机地址划分为2部分，子网网络地址和子网主机地址。
未做子网划分的IP 地址：网络地址＋主机地址
做子网划分后的 IP 地址：网络地址＋（子网网络地址＋子网主机地址）

子网网络地址被划分成2位，那么子网地址就有4个，分别是00，01，10，11

公有IP和私有IP
私有IP自己管理，公有IP有组织统一管理。

3.3、IP地址和路由控制

IP地址的网络地址这一部分就是用于进行路由控制。
路由控制表中记录着网络地址和下一步应该发送至路由器的地址。在主机和路由器都有自己的路由器控制表。在发送IP包时，首先要确定IP包首部的目标地址，在从路由控制表中找与其地址具有相同网络地址的记录，根据记录将IP包转发给下一个路由器，如果路由控制表存在多条相同网络地址的记录，就选择相同位数最多的网络地址，也就是最长匹配。

①主机A要发送一个IP包，其源地址为10.1.1.30和目标地址10.1.2.10，由于没有在主机A的路由表中找到与目标地址相同的网络地址，于是就转发给默认路由（路由器1）；②路由器1收到IP包后，在自身路由表上匹配到了与目标地址相同的网络地址记录，于是发送给路由器2；③路由器2收到后，同样在自己的路由表上匹配，于是这个IP包从路由器的10.1.2.1这个接口出去，最终经过交换机把IP包转发给目标主机。

环回地址是不会流向网络的。环回地址是在同一台计算机程序之间进行网络通信时使用的一个默认地址。计算机使用一个特殊的IP地址127.0.0.1作为环回地址。与该地址具有相同意义的是一个叫localhost的主机名。使用该地址或主机名，数据就不会流向网络。

3.4、IP分片与重组

每种数据链路的最大传输单元MTU都是不相同的。最常见的以太网的MTU是1500字节。当IP数据包的大小大于MTU时，就会被分片。经过分片的IP数据只能在目标主机进行重组，路由器是不会进行重组的。一旦在分片传输中，丢失了某个片段，就会使得整个IP数据报作废。所以一般的IP数据不会大于MTU（在TCP层引入MSS，在TCP层进行分片）

3.5、IPv6

IPv4的地址是32位的，IPv6是128位的，不仅是可分配地址变多了，其次IPv6可自动配置，即使没有DHCP服务器也可以实现自动分配IP地址，IPv6包头首部长度采用固定的值40字节，去掉了包头校验和，简化了首部结构，减轻了路由器负荷，提高了传输性能。也有应对伪造IP地址的安全功能和防止窃听的功能，提高了安全性。但IPv6和IPv4不能兼容，所以还没有普及。

IPv6长度为128位，以16位作为一组，用:隔开。用16进制表示。出现连续多组零，可以省略，用::隔开，但是一个IP只能允许省略一次。

3.5.1、IPv6结构

3.5.2、IPv4和IPv6的差别

3.6、IP协议

3.6.1、DNS域名解析

Domain Name System
域名容易记忆，所以我们通常使用的是域名，而不是IP地址，将域名网址自动转换为具体的IP地址，使用的就是DNS域名解析。
域名的层级关系
如www.baidu.com；越靠右的位置表示层级越高。
首先是根DNS服务器，其次顶级域DNS服务器(com)，在其次是权威DNS服务器(baidu.com)

根域的DNS服务器信息保存在所有的DNS服务器中，因此任何DNS服务器都可以找到访问根域DNS服务器，然后一路往下找到下层的某台目标DNS服务器。
域名解析流程
首先浏览器会查看自己的缓存里有没有，如果没有就向操作系统的缓存要，还没有就检测本机域名解析文件hosts，如还没有，就会向DNS服务器进行查询，如下：①客户端首先会发出一个DNS请求，www.xxx.com的IP是啥？并发给本地DNS服务器（TCP/IP设置中填写的DNS服务器地址）。②本地域名服务器收到客户端请求后，如果在缓存内找到，就返回对应IP，如果没有，就会去问它的根域名服务器；③根域DNS收到后，根据后置的.com，会将.com顶级域DNS的地址发给本地DNS服务器。④本地域DNS收到顶级域名DNS服务器地址后，就会去问它要。⑤顶级域DNS收到请求后，会将负责xxx.com的权威域DNS地址发送给本地域DNS服务器。⑥本地域DNS服务器就会去问权威DNS服务器要对应IP是什么。⑦权威DNS服务器查询后会将对应IP告诉给本地DNS服务器。⑧本地DNS服务器会将结果返回给客户端，客户端与目标建立连接。

3.6.2、DNS采用TCP还是UDP？

DNS占用53号端口，同时使用TCP和UDP协议。
1️⃣DNS在进行区域传输的时候使用TCP协议；DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送。为什么区域传输要使用TCP呢？①区域传输的数据量要大很多；②区域传输对数据得可靠性要求高很多。
2️⃣查询域名的时候使用UDP协议，客户端向DNS服务器查询域名，①一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。②当域名解析的反馈报文的长度超过512字节时，将不能使用udp协议进行解析，此时必须使用tcp。通常传统的UDP报文一般不会大于512字节。

3.6.3、ARP与RARP协议

address resolution protocol 地址解析协议

是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。地址解析协议是建立在网络中各个主机互相信任的基础上的，局域网络上的主机可以自主发送ARP应答消息，其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存；

RARP（Reverse Address Resolution Protocol）反向地址解析协议
反向地址转换协议（RARP）允许局域网的物理机器从网关服务器的 ARP 表或者缓存上请求其 IP 地址。网络管理员在局域网的网关路由器里创建一个表以映射物理地址（MAC）和与其对应的 IP 地址。当设置一台新的机器时，其 RARP 客户机程序需要向路由器上的 RARP 服务器请求相应的 IP 地址。假设在路由表中已经设置了一个记录，RARP 服务器将会返回 IP 地址给机器，此机器就会存储起来以便日后使用。 RARP 可以使用于以太网、光纤分布式数据接口及令牌环 LAN等。

3.6.4、DHCP动态获取IP地址

DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）

①客户端启动时，发现本机没有任何IP设定，将以广播方式通过UDP 67端口发送DHCP Discover 来寻找DHCP服务器，因为本机不知道自己属于哪一个网路，所以包内的源地址0.0.0.0，目的地址255.255.255.255，向网络发送特定的广播信息，只有DHCP服务器收到后会响应。
②DHCP服务器收到客户端发出的DHCP discover广播后，通过解析报文，查询dhcpd.conf配置文件。它会从那些还没有租出去的地址中，选择最前面的空置IP，连同其它TCP/IP设定，通过UDP 68端口响应给客户端一个DHCP offer数据包（包中包含IP地址、子网掩码、地址租期等信息）。告诉DHCP客户端，该DHCP服务器拥有资源，可以提供DHCP服务。此时还是使用广播进行通讯，源IP地址为DHCP服务器的IP地址，目标地址255.255.255.255。同时，DHCP服务器为此客户端保留它提供的IP地址，从而不会为其他DHCP客户分配此IP地址。由于客户端在开始的时候还没有IP地址，所以在其DHCP discover封包内会带有其MAC地址信息，并且有一个XID编号来辨别该封包，DHCP服务器响应的DHCP offer封包则会根据这些资料传递给要求租约的客户。
③DHCP客户端接受到DHCP offer提供信息之后，如果客户机收到网络上多台DHCP服务器的响应，一般是最先到达的那个，然后以广播的方式回答一个DHCP request数据包（包中包含客户端的MAC地址、接受的租约中的IP地址、提供此租约的DHCP服务器地址等）。告诉所有DHCP服务器它将接受哪一台服务器提供的IP地址，所有其他的DHCP服务器撤销它们的提供以便将IP地址提供给下一次IP租用请求。此时，由于还没有得到DHCP服务器的最后确认，客户端仍然使用0.0.0.0为源IP地址，255.255.255.255为目标地址进行广播。事实上，并不是所有DHCP客户端都会无条件接受DHCP服务器的offer，特别是如果这些主机上安装有其它TCP/IP相关的客户机软件。客户端也可以用DHCP request向服务器提出DHCP选择，这些选择会以不同的号码填写在DHCP Option Field里面。客户机可以保留自己的一些TCP/IP设定。。
④当DHCP服务器接收到客户机的DHCP request之后，会广播返回给客户机一个DHCP ack消息包，表明已经接受客户机的选择，告诉DHCP客户端可以使用它提供的IP地址。并将这一IP地址的合法租用以及其他的配置信息都放入该广播包发给客户机。
客户端在接收到DHCP ack广播后，会向网络发送三个针对此IP地址的ARP解析请求以执行冲突检测，查询网络上有没有其它机器使用该IP地址；如果发现该IP地址已经被使用，客户机会发出一个DHCP decline数据包给DHCP服务器，拒绝此IP地址租约，并重新发送DHCP discover信息。此时，在DHCP服务器管理控制台中，会显示此IP地址为BAD_ADDRESS。
如果网络上没有其它主机使用此IP地址，则客户机的TCP/IP使用租约中提供的IP地址完成初始化，从而可以和其他网络中的主机进行通讯。

重新登录：以后DHCP客户端每次重新登录网络时，就不需要再发送DHCP discover发现信息了，而是直接发送包含前一次所分配的IP地址的DHCP request请求信息。当DHCP服务器收到这一信息后，它会尝试让DHCP客户机继续使用原来的IP地址，并回答一个DHCP ack确认信息。如果此IP地址已无法再分配给原来的DHCP客户端使用时，则DHCP服务器给DHCP客户端回答一个DHCP nack否认信息。当原来的DHCP客户机收到此DHCP nack否认信息后，它就必须重新发送DHCP discover发现信息来请求新的IP地址。

更新租约：DHCP服务器向DHCP客户机出租的IP地址一般都有一个租借期限，期满后DHCP服务器便会收回出租的IP地址。如果DHCP客户机要延长其IP租约，则必须更新其IP租约。客户端会在租期过去50%的时候，直接向为其提供IP地址的DHCP服务器发送DHCP request消息包。如果客户端接收到该服务器回应的DHCP ack消息包，客户端就根据包中所提供的新的租期以及其它已经更新的TCP/IP参数，更新自己的配置，IP租用更新完成。如果没有收到该服务器的回复，则客户端继续使用现有的IP地址，因为当前租期还有50%。如果在租期过去50%的时候没有更新，则客户端将在租期过去87.5%的时候再次向为其提供IP地址的DHCP联系。如果还不成功，到租约的100%时候，客户端必须放弃这个IP地址，重新申请。如果此时无DHCP可用，客户端会使用169.254.0.0/16中随机的一个地址，并且每隔5分钟再进行尝试。

3.6.5、NAT 网络地址转换

Network Address Translation
NAT是将IP数据报报头中的IP地址转换为另一个IP地址的过程，主要用于实现内部网络（私有IP地址）访问外部网络（公有IP地址）的功能。Basic NAT实现一对一的IP地址转换，而NAPT实现多个私有地址映射到同一个公有地址上。
Basic NAT:一对一转换，只转换IP，而对TCP/IP协议的端口号不处理，一个公网IP地址不能同时被多个用户使用。不能有效解决IP地址短缺的问题，因此实际应用并不多。NAT服务器拥有的公有IP地址数目远远小于内部网络的主机数目。

NAPT Network Address Port Translation 网络地址端口转换，可以实现并发的地址转换，允许多个内部地址映射到同一个公有IP地址上，称为多对一地址转换或地址复用。通过使用IP地址+端口号的形式进行转换，是的多个私有用户可以共享一个公网IP地址访问外网。

NAT服务器收到内网主机发送的访问服务器的报文，比如收到主机A报文的源地址是192.168.1.10，端口号1025；NAT服务器从地址池中选取一对空闲的“公网IP+端口号”，建立与内网报文“源地址IP+源端口号”之间的NAPT转换表项（正反向），并根据查找正反向NAPT表项的结果将报文转换后向服务器发送；NAT收到服务器的回应报文，根据目标IP地址+目的端口号 查找反向NAPT表项，发送给内网主机。

NAT/NAPT的缺点：外部无法主动与NAT内部服务器建立连接，因为NAPT转换表没有转换记录。转换表的生成与转换操作都会产生性能开销；通信过程中，如果NAT重启了，所有的TCP连接都会被重置。
解决上述问题的方法：1️⃣ 改用IPv6,IPv6可用范围很大，以至于每台设备都可以配置一个公有IP地址，就不用搞花里胡哨的地址转换。2️⃣NAT穿透技术

3.6.6、ICMP 互联网控制报文协议

Internet Control Message Protocol
主要功能： 确认IP包是否成功送达目标地址、包好发送过程中IP包被弃用的原因和改善网络设置等。

ICMP包头格式

在IP通信中，当某个包因为某种原因没有到达目标地址时，ICMP可以负责通知这个未达原因。

ICMP分类：
1️⃣查询报文类型 用于诊断的查询信息；2️⃣差错报文类型 通知出错的错误原因；

虽然ICMP是网络层协议，但是它不像IP协议或ARP协议一样直接传递给数据链路层，而是先封装成IP数据包然后在传递给数据链路层，故IP数据包协议类型字段的值为1，就是ICMP报文。

3.6.7、IGMP 因特网组管理协议

TCP/IP协议族中负责IPv4组播成员管理的协议。
作用：用来在接收者主机和直接相邻的组播路由器之间建立和维护组播组成员的关系；通过在接收者主机和组播路由器之间交互IGMP报文实现组成员管理功能，IGMP封装在IP报文中。
IGMP有三个版本
IGMPv1：主要基于查询和响应机制来完成对组播组成员的管理。首先在一个网段内有多台组播路由器时，由于他们都能从主机收到IGMP成员关系报文，因此，只需要其中一台路由器发送IGMP查询报文即可，由组播路由协议来选举出唯一的组播信息转发者作为IGMP查询器。
主机加入和IGMP查询器维护组播组成员的过程如下：1️⃣主机主动发送IGMP成员关系报告报文带其要加入的组播组，不用等待IGMP查询器的查询报文。2️⃣IGMP查询器周期性以组播方式，向本网段内的所有主机与路由器发送IGMP查询报文。3️⃣在收到查询报文后，关注同一个组播组的成员（取决于延迟定时器）其中的某一个首先以组播方式向组播组发送IGMP成员关系报文，其他成员收到这个后，就不会在继续发送了。4️⃣IGMP路由器只要收到成员关系报文，就知道该组非空，就会继续转发。
但该版本没有定义离开组播组的报文。只有当网段中不在存在组播组成员后，IGMP就不会再转发了。
IGMPv2：
查询器选举机制：一开始所有的IGMPv2路由器都认为自己是查询器，并向该网段内所有主机和路由器发送IGMP普遍组查询报文（目的地址224.0.0.1），本网段中的其他IGMP路由器收到该报文后，将报文的源地址和自己的接口地址比较，IP地址最小的路由器成为查询器。所有的非查询器都会启动一个定时器，在超时前，收到来自查询器的IGMP报文，就重启定时器，否则，就又开始上述过程，重新选举查询器。
主机加入和IGMP查询器维护组播组成员和v1一致
离开组机制：当一个主机离开某组播组时，该主机向本网段内所有组播路由器（224.0.0.2）发送离开祖报文，当查询器收到后，向本组发送特定组查询报文（目的地址和组地址都为索要查询的组播组地址）。如果该网段还有该组播组成员，这些成员收到后，会在该报文所设定的响应时间内发送成员关系报告报文。在指定响应时间内收到成员关系报文，查询器就继续维护该组播组的成员关系，否则，就不在维护。
IGMPv3更强。 主机控制能力更强，增加了针对组播源的过滤模式。增加了对特定源组查询。
在这里插入图片描述

3.7、ICMP的应用

3.7.1、ping

3.7.2、traceroute

四、浏览器输入URL之后的过程

1、DNS域名解析；
2、建立TCP连接；
3、发送HTTP请求、服务器处理请求、返回响应结果；
4、关闭TCP连接；
5、浏览器渲染；
6、浏览器发送湖区镶嵌在HTML中的其他内容；