计算机网络知识总结

​​​​​​​​​​​​​​​​​​网络模型

OSI七层参考模型

OSI（Open System Interconnection）模型，即开放式系统互联，是国际标准化组织（ISO）制定的⼀个⽤于计算 机或通信系统间互联的标准体系，旨在将计算机⽹络通信划分为七个不同的层级，每个层级都负责特定的功能。每 个层级都构建在其下⽅的层级之上，并为上⽅的层级提供服务。七层从下到上分别是物理层、数据链路层、⽹络层、传输层、会话层、表示层和应⽤层。可以简称为“物数⽹传会表应”。

TCP/IP四层网络模型

TCP/IP模型是⼀种⽤于组织和描述计算机⽹络通信的标准模型，它是互联⽹最常⽤的协议栈。TCP/IP模型由两个主要协议组成：TCP（Transmission Control Protocol）和IP（Internet Protocol）。它是互联⽹通信的基础，也被⼴泛⽤于局域⽹和⼴域⽹等各种⽹络环境。

两个网络模型对比

在浏览器中输⼊URL并按下回⻋之后会发⽣什么

第一步：输入URL并解析
输⼊URL后，浏览器会解析出协议、主机、端⼝、路径等信息，并构造⼀个HTTP请求（浏览器会根据请求头判断是否有HTTP缓存,并根据
是否有缓存决定是从服务器获取资源还是使⽤缓存资源，具体内容见HTTP缓存章节）

第二步：DNS域名解析
在发送HTTP请求之前，浏览器需要知道想要访问⽹⻚(url)对应的IP地址，这就需要使⽤到解析的具体内容也会在后⾯章节中讲解）。

第三步：建立起TCP连接之三次握手

第四步：浏览器发送HTTP/HTTPS请求给web服务器

第五步：服务器处理HTTP请求并返回HTTP报文

第六步：浏览器渲染页面

第七步：断开TCP连接之四次挥手

DNS

是什么

DNS（Domain Name System）是⼀种⽤于将域名（例如www.baidu.com ）转换为IP地址（例如 220.181.111.188 ）的分布式系统。

层次关系

DNS 中的域名都是⽤句点来分隔的，⽐如 www.server.com 在域名中，越靠右的位置表示其层级越⾼。

解析过程

1. 首先用户在浏览器输入URL地址后，会先查询浏览器缓存是否有该域名对应的IP地址
2. 如果浏览器缓存中没有，会去计算机本地的Host文件中查询是否有对应的缓存
3. 如果Host文件中也没有，则会向本地的DNS解析器（通常由你的互联网服务提供商（ISP）提供）发送一个DNS查询请求
4. 如果本地DNS解析器没有缓存该域名的解析记录，它会向根DNS服务器发送查询请求。根DNS服务器并不负责解析域名，但它能告诉本地DNS解析器应该向哪个顶级域（.com/.net/.org）的DNS服务器继续查询
5. 本地DNS解析器接着向指定的顶级域DNS服务器发出查询请求。顶级DNS服务器也不负责具体的域名解析，但它能告诉本地DNS服务器应该前往哪个权威DNS服务器查询下一步的信息
6. 本地DNS解析器最后向权威DNS服务器发送查询请求。权威DNS服务器是负责存储特定域名和IP地址映射的服务器。当权威DNS服务器收到查询请求时，它会查找"example.com"域名对应的IP地址，并将结果返回给本地DNS解析器
7. 本地DNS解析器将收到的IP地址返回给浏览器，并且还会将域名结果缓存在本地，以便下次访问时更快地响应

HTTP

HTTP特性

简单

基本报⽂格式为header+body，头部信息也是key-value简单⽂本的形式，易于理解。

灵活和易于扩展

HTTP协议⾥的各种请求⽅法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，允许开发⼈员⾃定义和扩充;
HTTP⼯作在应⽤层（OSI第七层），下层可以随意变化;
HTTPS就是在HTTP与TCP之间增加了SSL/TSL安全传输层，HTTP/3把TCP换成了基于UDP的QUIC。

⽆状态、明⽂传输、不安全

⽆状态

服务器不会去记忆HTTP的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担。但它在完成有关联性的操作时会⾮常麻烦。

对于⽆状态的问题，解决⽅案有很多种，其中⽐较简单的⽅式的是 Cookie 技术，Cookie 通过在请求和响应报⽂中写⼊ Cookie 信息来控制客户端的状态。

明⽂传输

传输过程中的信息，是可⽅便阅读的，通过浏览器的F12控制台或Wireshark抓包都可以直接⾁眼查看。
明⽂传输为我们调试⼯作带来了极⼤的便利性，但信息透明，容易被窃取。

不安全

1. 通信使⽤明⽂（不加密），内容可能被窃听
2. 不验证通信⽅的身份，因此有可能遭遇伪装
3. ⽆法证明报⽂的完整性，所以有可能已遭篡改

可以⽤ HTTPS 的⽅式解决，也就是通过引⼊ SSL/TLS 层，使得在安全上达到了极致。

HTTPS

HTTPS的特点

1. 特点
   针对HTTP的三大不安全特性做提升

信息加密：采⽤对称加密+⾮对称加密的混合加密的⽅式，对传输的数据加密，实现信息的机密性，解决了窃听的⻛险。
校验机制：⽤摘要算法为数据⽣成独⼀⽆⼆的「指纹」校验码，指纹⽤来校验数据的完整性，解决了被篡改的⻛险。
身份证书：将服务端的公钥放⼊到CA数字证书中，解决了服务端被冒充的⻛险。

3. 优点
   在数据传输过程中，使⽤秘钥加密，安全性更⾼
   可认证⽤户和服务器，确保数据发送到正确的⽤户和服务器

4. 缺点
   握⼿阶段延时较⾼：在会话前还需进⾏SSL握⼿
   部署成本⾼：需要购买CA证书；需要加解密计算，占⽤CPU资源，需要服务器配置或数⽬⾼

HTTPS和HTTP的区别

传输安全性：HTTP以明⽂的⽅式在⽹络中传输数据，HTTPS 解决了HTTP 不安全的缺陷，在 TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS安 全协议，使得报⽂能够加密传输。

SSL/TLS 握⼿：HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。

端口号：HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。

数字证书：HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

SSL/TSL

SSL：Secure Socket Layer 安全套接字
TSL：Transport Layer Security 安全传输层协议

HTTPS（HyperText Transfer Protocol Secure）是基于TLS/SSL的安全版本的HTTP协议

SSL和TLS协议通过以下⽅式确保安全通信：

• 加密： 使⽤加密算法对传输的数据进⾏加密，防⽌第三⽅截取和读取敏感信息。
• 身份验证： 使⽤数字证书验证通信双⽅的身份，确保数据传输的可信性。
• 数据完整性： 通过使⽤消息摘要算法，确保传输的数据在传输过程中没有被篡改或损坏。

加密

对称加密

对称加密也称为私钥加密，使⽤相同的密钥来进⾏加密和解密。

在加密过程中，明⽂数据通过应⽤特定的算法和密钥进⾏加密，⽣成密⽂数据。解密过程则是将密⽂数据应⽤同样的算法和密钥进⾏解密，恢复为明⽂数据。

由于加密和解密都使⽤相同的密钥，因此对称加密算法的速度通常较快，但密钥的安全性很重要。如果密钥泄漏，攻击者可以轻易地解密数据。

⾮对称加密

⾮对称加密也称为公钥加密，使⽤⼀对不同但相关的密钥：公钥和私钥。

公钥⽤于加密数据，私钥⽤于解密数据。如果使⽤公钥加密数据，只有拥有相应私钥的⼈才能解密数据；如果使⽤私钥加密数据，可以使⽤相应公钥解密。

除了加密和解密，⾮对称加密还⽤于【数字签名】，可以验证消息的来源和完整性。

摘要算法+数字签名

为了保证传输的内容不被修改，可以将传输的内容计算出⼀个【指纹】，对⽅收到后，也把接收的内容计算出⼀个【指纹】，然后进⾏对⽐，如果【指纹】相同，则说明内容没有被篡改，常常会使⽤摘要算法（哈希函数）来计算出内容的哈希值，通过摘要算法可以⽣成数据的唯⼀标识，从⽽验证数据的完整性。

但是摘要算法只能保证内容不被修改，不能保证发送者的身份，为了避免这种情况，计算机⾥会⽤⾮对称加密算法来解决，共有两个密钥：公钥⽤于验证签名，私钥⽤于⽣成签名。私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。

1. ⽣成数字签名：
   发送者使⽤私钥对消息的摘要（通常是通过哈希函数计算得到）进⾏加密，⽣成数字签名。
   数字签名是消息的哈希值经过私钥加密的结果。
2. 发送消息和数字签名：
   发送者将原始消息和⽣成的数字签名⼀起发送给接收者。
3. 验证数字签名：
   接收者收到消息和数字签名后，使⽤发送者的公钥对数字签名进⾏解密，得到摘要值。
   接收者再次计算收到的消息的摘要（使⽤相同的哈希函数），将其与解密得到的摘要值进⾏⽐较。
   如果两个摘要值相同，说明消息未被篡改过，数字签名有效，消息来源可信。
   

数字证书

根据上⾯的介绍，我们已经知道可以通过摘要算法保证内容不被修改，以及通过私钥和公钥保证消息来源的可靠性，但是却缺少身份验证的环节，如果此时在客户端和服务器之间有⼀个中间⼈，中间⼈把原本双⽅通信的公钥篡改成⾃⼰的公钥，这⼜该怎么办呢？这就需要使⽤到数字证书。

1. 密钥⽣成：
   ⾸先，实体（例如服务器、个⼈或组织）需要⽣成⼀对密钥：公钥和私钥。
   公钥是⽤于加密和验证的，可以被公开分享。
   私钥⽤于解密和签名，必须保密，只有持有者知道。

2. 证书请求（CSR - Certificate Signing Request）：
   实体⽣成⼀个证书请求，其中包含公钥、实体信息（如名称、电⼦邮件等）和签名。
   CSR是⼀个包含有关实体信息的⽂本块，可以被发送到数字证书颁发机构（CA）以获取数字证书。

3. 证书颁发：
   实体将证书请求发送给数字证书颁发机构（CA）。
   CA会验证请求者的身份，然后使⽤⾃⼰的私钥对请求中的信息进⾏签名，⽣成数字证书。
   数字证书包括公钥、实体信息、CA的信息和签名等内容。

4. 证书验证：
   当实体收到数字证书时，它可以使⽤CA的公钥验证证书的签名，确保证书未被篡改且由合法的CA签发。
   接收者可以检查证书中的实体信息以及CA的信息，确保证书的合法性。

5. 数字证书使⽤：
   接收者可以使⽤数字证书中的公钥来加密数据，然后发送给证书的持有者。
   持有者使⽤私钥解密数据，保护数据的机密性。
   持有者还可以使⽤私钥⽣成数字签名，接收者使⽤公钥验证签名，验证数据的来源和完整性。
   

HTTPS传输过程

SSL/TLS 协议基本流程：

1. 客户端向服务器索要并验证服务器的公钥。
2. 双⽅协商⽣产「会话秘钥」。
3. 双⽅采⽤「会话秘钥」进⾏加密通信。

具体流程如下：

1. ⾸先，客户端向服务器端发送加密通信请求，也就是 ClientHello 请求，请求与服务端建⽴连接。
2. 服务端产⽣⼀对公私钥，然后将⾃⼰的公钥发送给CA机构，CA机构也有⼀对公私钥，然后CA机构使⽤⾃⼰的私钥将服务端发送过来的公钥进⾏加密，产⽣⼀个CA数字证书。
3. 服务端响应客户端的请求，也就是 SeverHello ， 将CA机构⽣成的数字证书发送给客户端。
4. 客户端将服务端发送过来的数字证书进⾏解析(因为浏览器产商跟CA机构有合作，所以浏览器中已经保存了⼤部分CA机构的密钥，⽤于对服务端发送过来的数字证书进⾏解密)，验证这个CA数字证书是否合法，如果不合法，会发送⼀个警告。如果合法，从数字证书中取出服务端⽣成的公钥。
5. 客户端取出公钥并⽣成⼀个随机码key（其实就是对称加密中的密钥）
6. 客户端将加密后的随机码key发送给服务端，作为接下来的对称加密的密钥
7. 服务端接收到随机码key后，使⽤⾃⼰的私钥对它进⾏解密，然后获得到随机码key。
8. 服务端使⽤随机码key对传输的数据进⾏加密，在传输加密后的内容给客户端
9. 客户端使⽤⾃⼰⽣成的随机码key解密服务端发送过来的数据，之后，客户端和服务端通过对称加密传输数据，随机码Key作为传输的密钥。

HTTP版本

HTPP1.0和HTTP1.1有什么区别

1. ⻓连接
   HTTP1.1 ⽀持⻓连接，每⼀个TCP连接上可以传送多个HTTP请求和响应，默认开启 Connection:Keep-Alive
   HTTP1.0 默认为短连接，每次请求都需要建⽴⼀个TCP连接。

2. 缓存
   HTTP1.0 主要使⽤ If-Modified-Since/Expires 来做为缓存判断的标准
   HTTP1.1 则引⼊了更多的缓存控制策略例如 Entity tag / If-None-Match 等更多可供选择的缓存头来控制缓存策略。

3. 管线化
   基于 HTTP1.1 的⻓连接，使得请求管线化成为可能。管线化使得请求能够“并⾏”传输，但是响应必须按照请求发出的顺序依次返回，性能在⼀定程度上得到了改善。

4. 增加Host字段
   使得⼀个服务器能够⽤来创建多个 Web 站点。

5. 状态码
   新增了24个错误状态响应码

6. 带宽优化
   HTTP1.0 中，存在⼀些浪费带宽的现象，例如客户端只是需要某个对象的⼀部分，⽽服务器却将整个对象送过来了，并且不⽀持断点续传功能
   HTTP1.1 则在请求头引⼊了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content）
   
   

HTPP1.1和HTTP2.0有什么区别

1. 传输格式变化，采⽤了新的⼆进制格式
   HTTP1.X 的解析都是基于⽂本，⽂本的表现形式多样，不利于健壮性考虑
   HTTP2.0 采⽤⼆进制，只认0/1组合，实现更加快的⽅法，健壮性更加完善

2. 多路复⽤
   连接共享，每个连接都可以有多个请求，⼀个请求对应⼀个ID
   接收⽅可以根据请求的ID将请求再归属到各⾃不同的服务端请求中，可以极⼤的提⾼效率
   这个强⼤的功能则是基于“⼆进制分帧”的特性。

3. header压缩
   在HTTP1.X中，header带有⼤量信息，⽽且每次都要重复发送
   HTTP2.0通过encoder减少header⼤⼩，通讯双⽅会各⾃缓存⼀份header字段表
   既可以避免重复header传输，⼜减⼩了需要传输的⼤⼩

4. 服务端推送
   把客户端所需要的资源伴随着index.html⼀起发送到客户端，省去了客户端重复请求的步骤
   因为没有发起请求，建⽴连接等操作，所以静态资源通过服务器推送，可以极⼤的提升速度

HTPP2.0和HTTP3.0有什么区别

HTTP报文

HTTP请求报文

具体组成

1. 请求⾏（Request Line） ：(请求⽅法 URI 协议版本号)
   请求⽅法： GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE
   URL： <协议>：//<主机>：<端⼝>/<路径>?<参数>
   协议版本号： HTTP版本号

2. 请求头（Request Header）：包含请求的附加信息，有key：value组成, 它可以包含很多不同的字段，⽤于告知服务器有关请求的详细信息。

3. 空⾏（Empty Line）： 空⾏是请求头部和请求主体之间的空⾏，⽤于分隔请求头部和请求主体。

4. 请求体（Request Body）：承载多个请求参数的数据, 请求主体是可选的，通常在发送POST、PUT等请求时包含请求的实际数据。例如，在使⽤POST请求提交表单数据或上传⽂件时，请求主体会包含这些数据。
   
   

示例

GET /example/index.html HTTP/1.1
 Host: example.com
 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng, */*;q=0.8

HTTP请求方法类别

1. GET：申请获取资源，不对服务器产⽣影响
2. POST：POST请求通常⽤于发送数据，例如提交表单数据、上传⽂件等，会影响服务器，服务器可能动态创建新的资源或更新原有资源。
3. HEAD：类似GET，仅要求服务器返回头部信息，不返回实际的资源内容。
4. PUT：⽤于更新服务器上的资源或创建新资源。
5. DELETE：请求服务器删除指定的资源。
6. TRACE：⽤于测试。要求⽬标服务器返回原始的HTTP请求内容
7. PATCH： ⽤于对资源进⾏部分更新。
8. CONNECT：⽤于代理服务器
9. OPTIONS：⽤于获取服务器⽀持的HTTP⽅法列表，以及针对指定资源⽀持的⽅法

GET请求和POST请求的区别

请求报⽂

GET请求的参数⼀般写在URL中，所以GET传送的数据量较⼩，不能⼤于2KB，且只接受ASCII字符
POST请求参数⼀般放在请求体中，所以其请求信息没有⻓度限制， 对于数据类型也没有限制。最后⼀⾏name…为请求数据，且请求数据和请求头之间必须空出⼀⾏

安全和幂等

安全：HTTP协议中，安全是指请求⽅法不会破坏服务器上的资源

幂等：多次执⾏相同的操作，结果都相同
GET为安全幂等的，因为它为只读操作，⽆论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的
POST因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

缓存机制

GET 请求会被浏览器主动cache，如果下⼀次传输的数据相同，那么就返回缓存中的内容，以求更快的展示数据，⽽ POST 不会，除⾮⼿动设置。
GET 请求参数会被完整保留在浏览器历史记录⾥，⽽ POST 中的参数不会被保留。
GET 产⽣的 URL 地址可以被保存为书签，⽽ POST 不可以。
GET 在浏览器回退时是⽆害的，⽽ POST 会再次提交请求。

时间消耗

GET 产⽣⼀个 TCP 数据包：浏览器会把 header 和 data ⼀并发送出去，服务器响应 200（返回数据）
POST 产⽣两个 TCP 数据包，对于 POST，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）

编码⽅式

GET 请求只能进⾏ URL 编码 application/x-www-form-urlencoded
POST ⽀持多种编码⽅式 application/x-www-form-urlencoded 或 multipart/form-data 。为⼆进制数据使⽤多种编码。

HTTP响应报文

具体组成

1. 状态行（Status Line）：状态⾏包括三个主要部分，⽤空格分隔：

  HTTP协议版本（通常是"HTTP/1.1"）
  状态码（表示服务器处理结果的三位数字代码）
  状态消息（对状态码的简要描述）

2. 响应头部（Response Headers）：响应头部也是以键值对的形式提供的额外信息，类似于请求头部，⽤于告知客户端有关响应的详细信息。

3. 空⾏（Empty Line）： 空⾏是响应头部和响应主体之间的空⾏，⽤于分隔响应头部和响应主体。

4. 响应主体（Response Body）：响应主体包含服务器返回给客户端的实际数据。例如，当请求⼀个⽹⻚时，响应主体将包含HTML内容。响应主体的存在与否取决于请求的性质以及服务器的处理结果。
   
   

示例

HTTP/1.1 200 OK
 Content-Type: text/html; charset=UTF-8
 Content-Length: 1234
 Server: Apache/2.4.38 (Unix)
 Set-Cookie: session_id=abcd1234; Expires=Wed, 11 Aug 2023 00:00:00 GMT
 
 <!DOCTYPE html>
 <html>
 <head>
  <title>Example Page</title>
 </head>
 <body>
  <h1>Hello, World!</h1>
 </body>
 </html>

HTTP状态码类别

HTTP常见字段

通⽤头部字段（General Headers）：
Cache-Control：指定缓存策略。
Connection：控制连接的⾏为。
Date：指定⽇期和时间。

请求头部字段（Request Headers）：
Accept：指定客户端能够接受的响应的MIME类型。
Accept-Encoding：指定客户端⽀持的内容编码⽅式。
Authorization：⽤于进⾏身份验证的凭据。
Host：指定请求的⽬标主机和端⼝。
User-Agent：标识客户端的⽤户代理（浏览器或其他⼯具）。

响应头部字段：
Content-Type：指定响应主体的MIME类型。
Content-Length：指定响应主体的⻓度（字节数）。
Server：指定服务器的信息。
Location：在重定向时指定新的资源位置。
Set-Cookie：在响应中设置Cookie。

Keep-alive

是什么

Keep-alive 是⼀种 HTTP 协议的机制，也被称为 HTTP⻓连接
在启⽤ Keep-alive 的情况下，客户端和服务器在完成⼀个 HTTP 请求和响应后，并不⽴即关闭连接，⽽是继续保持连接处于打开状态。在连接保持打开的情况下，客户端可以继续发送其他请求，服务器可以继续发送响应，⽽⽆需重新建⽴（TCP）连接，减少了连接的建⽴和关闭的开销，从⽽提⾼性能和效率。

优缺点

优点：
TCP 连接的建⽴和关闭需要时间和资源，通过保持连接打开，可以减少这些开销，从⽽提⾼性能和效率。
客户端可以在同⼀个连接上同时发送多个请求，服务器可以并⾏地处理这些请求，提⾼并发性能。
Keep-alive 连接中的多个请求共享同⼀个连接的头部信息（如⽤户代理、Cookie 等），减少了头部信息的重复传输。

缺点：
⻓时间的持久连接可能会占⽤服务器资源，特别是在⾼并发的情况下。为了平衡资源利⽤和性能，服务器和客户端通常会设置 Keep-alive 的超时时间，以便在⼀段时间内保持连接打开，超过该时间则关闭连接。

HTTP多个TCP连接怎么实现

多个tcp连接是靠某些服务器对 Connection: keep-alive 的 Header 进⾏了⽀持。简⽽⾔之，完成这个 HTTP 请求之后，不要断开 HTTP 请求使⽤的 TCP 连接。这样的好处是连接可以被重新使⽤，之后发送 HTTP 请求的时候不需要重新建⽴ TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免。

TCP KeepAlive是什么

TCP Keep-Alive 是在操作系统和⽹络协议栈级别实现的，它通过发送特定的探测数据包来维护连接的活跃性。

1. 在启⽤ TCP Keep-Alive 的情况下，操作系统会定期发送⼀些特定的探测数据包到连接的另⼀端。这些数据包通常是空的，没有实际的数据内容。
2. 如果⼀端收到了探测数据包，它会回复⼀个确认（ACK）数据包。如果⼀段时间内没有收到确认数据包，发送端将认为连接可能已经断开，从⽽触发连接关闭。
3. TCP Keep-Alive 的主要⽬的是检测连接是否处于空闲状态，即没有实际数据传输。它不仅可以检测到连接断开，还可以在空闲连接超过⼀定时间时释放连接，从⽽释放资源。

HTTP 的 Keep-Alive 和 TCP 的 Keepalive 是⼀个东⻄吗？

1. HTTP 的 Keep-Alive，是由应⽤层实现的，称为 HTTP ⻓连接
   每次请求都要经历这样的过程：建⽴ TCP -> 请求资源 -> 响应资源 -> 释放连接，这就是HTTP短连接，但是这样每次建⽴连接都只能请求⼀次资源，所以HTTP 的 Keep-Alive 实现了使⽤同⼀个 TCP 连接来发送和接收多个 HTTP 请求/应答，避免了连接建⽴和释放的开销，就就是 HTTP ⻓连接。

2. TCP 的 Keepalive，是由TCP 层（内核态）实现的，称为 TCP 保活机制，是⼀种⽤于在 TCP 连接上检测空闲连接状态的机制
   通俗地说，就是TCP有⼀个定时任务做倒计时，超时后会触发任务，内容是发送⼀个探测报⽂给对端，⽤来判断对端是否存活。

Cookie 和 Session

是什么

Cookie 和 Session 都⽤于管理⽤户的状态和身份, Cookie 通过在客户端记录信息确定⽤户身份，Session 通过在服务器端记录信息确定⽤户身份。

1. Cookie
   Cookie 是存储在⽤户浏览器中的⼩型⽂本⽂件，⽤于在⽤户和服务器之间传递数据。通常，服务器会将⼀个
   或多个 Cookie 发送到⽤户浏览器，然后浏览器将这些 Cookie 存储在本地。
   服务器在接收到来⾃客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息，从⽽动态⽣成与该客户端相对应的内容。

2. Session
   客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是 Session 。Session 主要⽤于维护⽤户登录状态、存储⽤户的临时数据和上下⽂信息等。

Cookie 工作原理

1. 客户端（浏览器）第⼀次发送请求到服务器
2. 服务器可以通过 HTTP 响应的头部信息中的 "Set-Cookie" 标头来创建⼀个 Cookie。这个标头指定了 Cookie 的名称、值和其他参数，如过期时间、域名、路径等。
3. 浏览器接收到 "Set-Cookie" 标头后，会将 Cookie 存储在⽤户的本地计算机上。
4. 当⽤户再次访问同⼀个⽹站时，浏览器会将与该域名相关的 Cookie 信息包括在 HTTP 请求的头部中。
5. 服务器收到包含 Cookie 的 HTTP 请求后，可以读取 Cookie 的值，根据其中的数据来判断⽤户的状态、偏好等，并根据需要做出相应的响应，如根据⽤户登录状态提供个性化内容。
6. 服务器可以通过发送新的 "Set-Cookie" 标头来更新 Cookie 的值或设置新的参数。
7. Cookie 可以设置过期时间，可以是会话级的（浏览器关闭时失效）或持久性的（在⼀段时间后失效）。当过期时间到达后，浏览器不再发送该 Cookie。
   

Session 工作原理

Session 是⼀种在服务器端存储和管理⽤户状态和数据的机制，通常基于会话标识符（Session ID）进⾏操作。

1. ⽤户⾸次访问⽹站时，服务器会为该⽤户创建⼀个唯⼀的会话标识符（Session ID）。这个标识符可以是⼀个加密的字符串，通常以 Cookie 的形式存储在⽤户的浏览器中。
2. 每个会话标识符对应着服务器上的⼀个会话存储空间。这个存储空间⽤于存储该⽤户在会话期间的状态和数据。
3. 当⽤户与服务器交互时，服务器可以通过会话标识符来访问对应的会话存储空间。服务器可以将数据存储在会话中，如⽤户的登录状态、购物⻋内容、⽤户偏好等。
4. 服务器为每个会话设置⼀个超时时间，如果⽤户在⼀段时间内没有活动，会话会⾃动过期。⼀旦会话过期，会话数据将被清除。
5. ⽤户可以⼿动终⽌会话，例如通过退出登录操作。这会导致服务器删除与该⽤户相关的会话数据。

区别

存储位置：Cookie 数据存储在⽤户的浏览器中，⽽ Session 数据存储在服务器上。
数据容量：Cookie 存储容量较⼩，⼀般为⼏ KB。Session 存储容量较⼤，通常没有固定限制，取决于服务器
的配置和资源。
安全性：由于 Cookie 存储在⽤户浏览器中，因此可以被⽤户读取和篡改。相⽐之下，Session 数据存储在服
务器上，更难被⽤户访问和修改。
传输⽅式：Cookie 在每次 HTTP 请求中都会被⾃动发送到服务器，⽽ Session ID 通常通过 Cookie 或 URL 参
数传递。

TCP

三次握手

过程

1. 第一次握手（SYN）
   客户端向服务器发送 SYN（同步Synchronize）报⽂、初始化序列号 ISN（seq=x），然后客户端进⼊ SYN_SEND 状态，等待服务器确认。

2. 第二次握手（SYN，ACK）
   服务端发送 ACK 确认服务端的 SYN 报文（ack=x+1），同时发出一个 SYN 报文，带上自己的初始化序列号（seq=y），然后服务端进⼊ SYN_RECV 状态。

3. 第三次握手（ACK）
   客户端接收到服务端的 SYN 、 ACK 报⽂，ACK确认服务端的 SYN 报文（ack=y+1），然后客户端和服务器端都进⼊ ESTABLISHED 状态，完成 TCP 三次握⼿。
   

携带数据

第三次握⼿是可以携带数据的，但是前两次握⼿是不可以携带数据的。

为什么需要三次握手，不是四次也不是两次

1. 三次握⼿才可以阻⽌重复历史连接的初始化(主因)

    1. 当因为⽹络阻塞原因，客户端向服务器发送了两次SYN报⽂
   
    2. 旧的SYN报⽂先到达服务端，服务端回⼀个ACK+SYN报⽂
   
    3. 客户端收到后可以根据⾃身的上下⽂，判断这是⼀个历史连接（序列号过期或超时），那么客户端就会发送 RST 报⽂给服务端，表示中⽌这⼀次连接。
   
    4. 服务器收到RST报⽂，会释放连接
   
    5. 新的SYN报⽂抵达之后，客户端和服务器之间进⾏正常的三次握⼿
   

如果只是两次握⼿，服务端在收到SYN报⽂之后，就进⼊到 ESTABLISHED 状态, 服务器端并不知道这次是历史连接，直接与客户端建⽴连接并向客户端发送数据（资源浪费），但是客户端会判定这次连接是历史连接，从⽽发送 RST报⽂来断开连接。

2. 三次握⼿才可以避免资源浪费

由于没有第三次握⼿，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的 ACK 确认信号，所以每收到⼀个 SYN 就只能先主动建⽴⼀个连接， 建⽴多个冗余的⽆效链接，造成不必要的资源浪费。

3. 三次握⼿才可以同步双⽅的初始序列号

TCP 协议的通信双⽅， 都必须维护⼀个「序列号」， 序列号是可靠传输的⼀个关键因素。

「两次握⼿」：⽆法防⽌历史连接的建⽴，会造成双⽅资源的浪费，也⽆法可靠的同步双⽅序列号；

「四次握⼿」：三次握⼿就已经理论上最少可靠连接建⽴，所以不需要使⽤更多的通信次数。

SYN攻击（洪水攻击）

什么是SYN攻击

我们都知道 TCP 连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的半连接队列，使得服务端不能为正常用户服务。

TCP半连接，全连接队列

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

半连接队列，也称 SYN 队列；
全连接队列，也称 accept 队列；

Linux 内核的 SYN 队列（半连接队列）与 Accpet 队列（全连接队列）正常工作流程：

当服务端接收到客户端的 SYN 报文时，会创建一个半连接的对象，然后将其加入到内核的「 SYN 队列」；
接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报文；
服务端接收到 ACK 报文后，从「 SYN 队列」取出一个半连接对象，然后创建一个新的连接对象放入到「 Accept 队列」；
应用通过调用 accpet() socket 接口，从「 Accept 队列」取出连接对象。
不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，默认情况都会丢弃报文。

SYN 攻击方式最直接的表现就会把 TCP 半连接队列打满，这样当 TCP 半连接队列满了，后续再在收到 SYN 报文就会丢弃，导致客户端无法和服务端建立连接。

如何避免SYN攻击

调大 netdev_max_backlog；
增大 TCP 半连接队列；
开启 tcp_syncookies；
减少 SYN+ACK 重传次数

四次挥手

过程

1. 客户端发送⼀个FIN（Finish）报⽂给服务端，表示自己要断开数据传送，报文中会指定一个序列号（seq=x）。然后客户端进入 FIN_WAIT_1 状态。

2. 服务端收到FIN报⽂后，回复⼀个ACK（确认）报⽂给客户端，且把客户端的序列号值+1，作为ACK报文的序列号（seq=x+1）。然后服务端进入 CLOSE_WAIT 状态，客户端进入 FIN_WAIT_2 状态。

3. 服务端也要断开连接时，发送 FIN 报文给客户端，且指定一个序列号（seq=y+1），随后服务端进入 LAST-ACK 状态。

4. 客户端收到服务器的FIN报⽂后，发送 ACK 报文作为应答，并把服务端的序列号+1作为 ACK 报⽂序列号（seq=y+2）。此时客户端进入 TIME_WAIT 状态。服务端在收到客户端的 ACK 报文后进入 CLOSE 状态。如果客户端等待 2MSL 没有收到回复，才关闭连接。
   

为什么是四次挥手

TCP 是全双⼯通信，可以双向传输数据。任何⼀⽅都可以在数据传送结束后发出连接释放的通知，待对⽅确认后进⼊半关闭状态。 当另⼀⽅也没有数据再发送的时候，则发出连接释放通知，对⽅确认后才会完全关闭了 TCP 连接。

总结：两次握⼿可以释放⼀端到另⼀端的 TCP 连接，完全释放连接⼀共需要四次握⼿

为什么需要 TIME_WAIT 状态

主动发起关闭连接的⼀⽅，才会有 TIME-WAIT 状态。
需要 TIME-WAIT 状态，主要是两个原因：

1. 防⽌历史连接中的数据，被后⾯相同四元组的连接错误的接收；
   如果⽹络出现拥塞或延迟，数据包可能会在⽹络中滞留⼀段时间，甚⾄超过了原始连接关闭的时间。如果没有 TIME_WAIT 状态，客户端直接进⼊到CLOSE状态，这些滞留的数据包可能会被传递给新连接，导致新连接的数据被旧连接的数据⼲扰。
   经过 2MSL 这个时间，⾜以让两个⽅向上的数据包都被丢弃，使得原来连接的数据包在⽹络中都⾃然消失，再出现的数据包⼀定都是新建⽴连接所产⽣的。
   
   

2. 保证「被动关闭连接」的⼀⽅能被正确的关闭，即保证最后的 ACK 能让被动关闭⽅接收，从⽽帮助其正常关闭
   如果最后的⼀次ACK报⽂丢失（第四次挥⼿），客户端没有 TIME_WAIT 状态，直接进⼊ClOSE，服务端⼀直在等待ACK状态，⼀直没有等到，就会重发FIN报⽂，⽽客户端已经进⼊到关闭状态，在收到服务端重传的 FIN 报⽂后，就会回 RST 报⽂,服务端收到这个 RST 并将其解释为⼀个错误, 为了防⽌这种情况出现，客户端必须等待⾜够⻓的时间，确保服务端能够收到 ACK，如果服务端没有收到 ACK，那么就会触发 TCP 重传机制，服务端会重新发送⼀个 FIN，这样⼀去⼀来刚好两个 MSL 的时间。

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

1. MSL是 Maximum Segment Lifetime ，报⽂最⼤⽣存时间，它是任何报⽂在⽹络上存在的最⻓时间，超过这个时间报⽂将被丢弃。
2. 等待MSL两倍：⽹络中可能存在发送⽅的数据包，当这些发送⽅的数据包被接收⽅处理后⼜会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间。
3. 1 个 MSL 确保四次挥⼿中主动关闭⽅最后的 ACK 报⽂最终能达到对端；1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报⽂可以到达。
4. 2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端⼜接收到了服务端重发的 FIN 报⽂，那么 2MSL 时间将重新计时。

重传机制

TCP 实现可靠传输的⽅式之⼀，是通过序列号与确认应答。
在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回⼀个确认应答消息，表示已收到消息。
但是如果传输的过程中，数据包丢失了，就会使⽤重传机制来解决。

超时重传

设定⼀个计时器，当超过指定的时间后，没有收到对⽅的确认ACK应答报⽂，就会重发该数据。
超时重传的两种情况如下：



RTT(round-trip time):往返时延,指的是数据包的往返时间



RTO（Retransmission Timeout）：超时重传时间
RTO较⻓或较短可能发⽣的情况如下（由图可知，超时重传时间RTO的值 应该略⼤于 报⽂往返RTT的值，且是动态变化的。）：

如果超时重发的数据，再次超时⼜要重传的时候，TCP的策略是将超时间隔加倍，也就是每当遇到⼀次超时重传的
时候，都会将下⼀次超时时间间隔设为先前值的两倍。

快速重传

快速重传（Fast Retransmit）机制，它不以时间为驱动，⽽是以数据驱动重传。

⼯作原理：
当收到三个相同的ACK报⽂时，会在定时器过期之前，重传丢失的报⽂段。
快速重传解决了超时时间的问题，但还⾯临另外⼀个问题：重传的时候，是重传之前的⼀个，还是重传所有的问
题。

SACK（Selective Acknowledgment,选择性确认）

为了解决 重传哪些报⽂的问题⽽提出。
这种⽅式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，可以将已收到的数据的信息发送给「发送⽅」，这
样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

D-SACK（Duplicate SACK）

主要使⽤了SACK来告诉【发送⽅】有哪些数据被重复接收了。下⾯举例来说明 D-SACK 的作⽤：
ACK丢包：



⽹络延时：

使⽤D-SACK的好处：
（1）可以让【发送⽅】知道，是发出去的包丢了，还是接收⽅回应的ACK包丢了；
（2）可以知道是不是【发送⽅】的数据包被⽹络演示了；
（3）可以知道⽹络中是不是把【发送⽅】的数据包给复制了。

滑动窗口

什么是窗⼝

TCP每发送⼀个数据，都需要⼀次应答，然后继续发送，这样为每个数据包都进⾏确认应答，缺点是：数据往返时间越⻓，⽹络吞吐量越低。为了解决这个问题，TCP 引⼊了窗⼝这个概念。即使在往返时间较⻓的情况下，它也不会降低⽹络通信的效率。⽽窗⼝的⼤⼩呢，就是⽆需等待确认应答，可以继续发送数据的最⼤值。假设窗⼝⼤⼩为 3 个 TCP 段，那么发送⽅就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下⼀个确认应答进⾏确认」。如下图：

窗⼝的实现就是操作系统开辟的⼀个缓存空间，发送⽅主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
图中的 ACK 600 确认应答报⽂丢失，也没关系，因为可以通过下⼀个确认应答进⾏确认，只要发送⽅收到了 ACK 700 确认应答，就意味着 700 之前的所有数据「接收⽅」都收到了。这个模式就叫累计确认或者累计应答。

什么决定窗⼝⼤⼩

TCP头部有⼀个字段叫 window ，窗⼝⼤⼩。
这个字段是接收端告诉发送端⾃⼰还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能⼒来
发送数据，⽽不会导致接收端处理不过来
通常窗⼝的⼤⼩是由接收⽅的窗⼝⼤⼩来决定的。
发送⽅发送的数据⼤⼩不能超过接收⽅的窗⼝⼤⼩，否则接收⽅就⽆法正常接收到数据。

发送方的滑动窗口

下图就是发送⽅缓存的数据，根据处理的情况分成四个部分：



下图，当收到之前发送的数据 32-36 字节的 ACK 确认应答后，如果发送窗⼝的⼤⼩没有变化，则滑动窗⼝往右边移动 5 个字节，因为有 5 个字节的数据被应答确认，接下来52-56 字节⼜变成了可⽤窗⼝，那么后续也就可以发送 52-56 这 5 个字节的数据了。



TCP 滑动窗⼝⽅案使⽤三个指针来跟踪在四个传输类别中的每⼀个类别中的字节。其中两个指针是绝对指针（指特定的序列号），⼀个是相对指针（需要做偏移）。

SND.WND ：表示发送窗⼝的⼤⼩（⼤⼩是由接收⽅指定的）；
SND.UNA ：是⼀个绝对指针，它指向的是已发送但未收到确认的第⼀个字节的序列号，也就是 #2 的第⼀个字节。
SND.NXT ：也是⼀个绝对指针，它指向未发送但可发送范围的第⼀个字节的序列号，也就是 #3 的第⼀个字节。
指向 #4 的第⼀个字节是个相对指针，它需要 SND.UNA 指针加上SND.WND ⼤⼩的偏移量，就可以指向 #4 的第⼀个字节了。

可⽤窗⼝⼤⼩ = 发送窗⼝ - 已发送未确定(SND.WND -（SND.NXT - SND.UNA))
已发送未确认 = (SND.NXT - SND.UNA)

接收方的滑动窗口

接收窗⼝根据处理的情况划分成三个部分：

其中三个接收部分，使⽤两个指针进⾏划分:
RCV.WND ：表示接收窗⼝的⼤⼩，它会通告给发送⽅。
RCV.NXT ：是⼀个指针，它指向期望从发送⽅发送来的下⼀个数据字节的序列号，也就是 #3 的第⼀个字节。
指向 #4 的第⼀个字节是个相对指针，它需要 RCV.NXT 指针加上RCV.WND ⼤⼩的偏移量，就可以指向 #4 的第⼀个字节了。

接收窗⼝和发送窗⼝的⼤⼩是相等的吗？

并不是完全相等，接收窗⼝的⼤⼩是约等于发送窗⼝的⼤⼩的。
因为滑动窗⼝并不是⼀成不变的。⽐如，当接收⽅的应⽤进程读取数据的速度⾮常快的话，这样的话接收窗⼝可以很快的就空缺出来。那么新的接收窗⼝⼤⼩，是通过 TCP 报⽂中的 Windows 字段来告诉发送⽅。那么这个传输过程是存在时延的，所以接收窗⼝和发送窗⼝是约等于的关系。

流量控制

TCP 流量控制的基本原理是使⽤滑动窗⼝机制，其中接收⽅可以通过调整窗⼝⼤⼩来告诉发送⽅其当前处理数据的能⼒。

1. 接收窗⼝：接收⽅维护⼀个接收窗⼝，表示可以接收的数据段的范围。窗⼝⼤⼩可以根据接收⽅的处理能⼒进⾏调整。

2. 通告窗⼝⼤⼩：接收⽅通过 TCP 报⽂中的确认信息，通告当前的接收窗⼝⼤⼩给发送⽅。发送⽅会根据这个窗⼝⼤⼩来控制发送数据的速率。

3. 窗⼝滑动：随着接收⽅处理数据的能⼒，窗⼝可以向前滑动。接收⽅可以通告更⼤的窗⼝，表示它可以接收更多的数据。

4. 发送速率控制：发送⽅会根据接收⽅通告的窗⼝⼤⼩来控制发送数据的速率。如果接收窗⼝变⼩，表示接收⽅的处理能⼒减弱，发送⽅会减慢发送速率，避免数据拥塞。

5. 动态调整：TCP 流量控制是动态的，适应⽹络和接收⽅的变化。如果⽹络拥塞或接收⽅的处理速度变慢，流量控制可以适时地减少发送速率。

拥塞控制

介绍

在⽹络出现拥堵时，如果继续发送⼤量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是⼀重传就会导致⽹络的负担更重，于是会导致更⼤的延迟以及更多的丢包，这个情况就会进⼊恶性循环被不断地放⼤…, 于是，就有了拥塞控制，控制的⽬的就是避免「发送⽅」的数据填满整个⽹络。
拥塞控制通过拥塞窗⼝来防⽌过多的数据注⼊⽹络，使得⽹络中的路由器或者链路过载。

拥塞窗⼝ cwnd 是发送⽅维护的⼀个状态变量，根据⽹络拥塞程度⽽变化。
发送窗⼝的值是 swnd = min(cwnd, rwnd) ，也就是拥塞窗⼝和接收窗⼝中的最⼩值。
⽹络中没有出现拥塞，cwnd增⼤，出现拥塞，cwnd减⼩。

其实只要发送⽅没有在规定时间内接收到 ACK 应答报⽂，也就是发⽣了超时重传，就会认为⽹络出现了拥塞。
拥塞控制的常⻅算法：慢启动、拥塞避免、拥塞发⽣、快速恢复

慢启动

TCP 在刚建⽴连接完成后，⾸先是有个慢启动的过程，这个慢启动的意思就是⼀点⼀点的提⾼发送数据包的数量。

慢启动的算法记住⼀个规则就⾏：当发送⽅每收到⼀个 ACK，拥塞窗⼝ cwnd 的⼤⼩就会加 1。

慢启动算法，发包的个数是指数性的增⻓。

不过，慢启动有⼀个⻔限
ssthresh 状态变量：

1. 当 cwnd < ssthresh 时，使⽤慢启动算法。
2. 当 cwnd >= ssthresh 时，就会使⽤拥塞避免算法。

拥塞避免

⼀般来说 ssthresh 的⼤⼩是65535字节。超过后会就会进⼊拥塞避免算法。
进⼊拥塞避免算法后，它的规则是：每当收到⼀个 ACK 时，cwnd 增加 1/cwnd。

现假定 ssthresh 为 8：
当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd ⼀共增加 1，于是这⼀次能够发送 9
个 MSS ⼤⼩的数据，变成了线性增⻓。

所以拥塞避免算法就是将原本慢启动算法的指数增⻓变成了线性增⻓，还是增⻓阶段，但是增⻓速度缓慢了⼀些。
不过⽹络就会慢慢进⼊了拥塞的状况了，就会出现丢包现象，这时就需要对丢失的数据包进⾏重传。

当触发了重传机制，也就进⼊了拥塞发⽣算法。

拥塞发生

当⽹络出现拥塞，也就是会发⽣数据包重传，重传机制主要有两种：
超时重传
快速重传

超时重传的拥塞发⽣算法

这个时候，ssthresh 和 cwnd 的值会发⽣变化

1. ssthresh 设为 cwnd/2
2. cwnd 重置为 1

接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是⼀旦「超时重传」，⻢上回到解放前。但是这种
⽅式太激进了，反应也很强烈，会造成⽹络卡顿。

快速重传的拥塞发生算法

TCP 认为这种情况不严重，因为⼤部分没丢，只丢了⼀⼩部分，则 ssthresh 和 cwnd 变化如下：

1. cwnd = cwnd/2 ，也就是设置为原来的⼀半
2. ssthresh = cwnd
3. 进⼊快速恢复算法

快速恢复

快速重传和快速恢复算法⼀般同时使⽤，快速恢复算法是认为，还能收到 3 个重复 ACK 说明⽹络也不那么糟糕，
所以没有必要像 RTO 超时那么强烈。

进⼊快速恢复：

1. 拥塞窗⼝ cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）；
2. 重传丢失的数据包；
3. 如果再收到重复的 ACK，那么 cwnd 增加 1；
4. 如果收到新数据的 ACK 后，把 cwnd 设置为第⼀步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进⼊拥塞避免状态；
   

TCP与UDP

各自概念和特点

1. TCP （传输控制协议）是⼀种⾯向连接的、可靠的、基于字节流的传输层通信协议。
   
   TCP是⼀种⾯向连接的协议，在通信之前，TCP需要在发送和接收⽅之间建⽴连接，然后在通信完成后关闭连接。这种连接的建⽴和关闭过程称为“三次握⼿”和“四次挥⼿”，确保可靠的数据传输。
   可靠性：TCP提供可靠的数据传输。它使⽤序列号和确认机制来确保数据包的有序性和完整性。如果数据包丢失或损坏，TCP会重新发送丢失的数据包，直到接收⽅正确接收为⽌。
   流量控制和拥塞控制：TCP使⽤流量控制和拥塞控制算法，确保数据发送的速率不会超过接收⽅的处理能⼒，并防⽌⽹络拥塞。
   有序传输：TCP确保数据包按照发送的顺序到达接收⽅，并在接收⽅重新组装成正确的顺序。

2. UDP （⽤户数据报协议）为应⽤程序提供了⼀种⽆需建⽴连接就可以发送封装的IP数据包的⽅法。
   
   UDP是⼀种⽆连接的协议：与TCP不同，UDP在通信之前不需要建⽴连接，直接发送数据包。这使得UDP⽐TCP更加轻量级。
   不可靠性：UDP不提供可靠的数据传输。它发送数据包后不会关⼼数据包是否成功到达接收⽅。因此，如果数据包丢失或损坏，UDP不会重新发送，也不会提供确认机制。
   速度较快：由于没有连接建⽴和确认过程，UDP传输速度较快，适⽤于实时传输，如实时⾳频和视频流。
   ⽆序传输：UDP不保证数据包的有序性，因此接收⽅接收到的数据包可能是⽆序的。

区别

1. 连接
   TCP 是⾯向连接的，在传输前需要三次握⼿建⽴连接。
   UDP 不需要连接，直接发送数据包，没有连接建⽴和关闭的过程。

2. 服务形式
   TCP 是⼀对⼀的通信。在TCP连接中，⼀台客户端与⼀台服务器之间建⽴⼀条连接，进⾏双向通信。
   UDP 可以是⼀对⼀、⼀对多或多对多的通信。UDP是⽆连接的，⼀个UDP包可以被⼴播到多个⽬标主机，或者从多个源主机接收UDP包。这使得UDP适⽤于多播和⼴播应⽤。

3. 可靠性
   TCP 保证数据可靠交付，拥有确认应答和重传机制，⽆重复、不丢失、按序到达。
   UDP 尽可能交付，发送数据后不会关⼼数据包是否成功到达接收⽅，不会进⾏重传，不保证可靠性。

4. 流量控制和拥塞控制
   TCP 拥有流量控制、拥塞控制，确保数据发送的速率不会超过接收⽅的处理能⼒，并防⽌⽹络拥塞。
   UDP 不进⾏流量控制和拥塞控制，数据发送的速率不受限制。

5. ⾸部开销
   TCP 的⾸部⼤⼩通常为20字节，但在选项字段被使⽤的情况下，可能会更⼤。TCP⾸部包含源端⼝号、⽬标端⼝号、序列号、确认号、窗⼝⼤⼩、校验和等字段。
   UDP 的⾸部⼤⼩固定为8字节。UDP⾸部包含源端⼝号、⽬标端⼝号、包⻓度和校验和字段（各16位）。

6. 传输⽅式
   TCP 基于字节流，没有边界，但是保证传输顺序和可靠性;
   UDP 继承了 IP 层特性，基于数据包，有边界可能出现乱序和丢包。

7. 分⽚⽅式
   TCP 数据⼤于MSS时会在 TCP 层将数据进⾏分⽚传输，到达⽬的地后同样在传输层进⾏合并，如果有某个⽚丢失则只需要重传丢失的分⽚即可;
   UDP 数据⼤于MTU时会在IP层分⽚，则会在IP层合并，如果某个IP分⽚丢失，⽬标主机收到后，在 IP 层组装完数据，接着再传给传输层。

各自使用场景

TCP：适⽤于可靠数据传输的场景：TCP适⽤于那些对数据传输可靠性要求较⾼的应⽤，如⽂件传输、电⼦邮件、⽹⻚浏览等。

UDP：适⽤于实时传输的场景：UDP适⽤于对数据传输可靠性要求不⾼的场景，如实时游戏、流媒体等，其中实时性⽐数据的准确性更为重要。

TCP如何确保可靠性

1. 数据块⼤⼩控制： 应⽤数据被分割成TCP认为最合适发送的数据块，再传输给⽹络层，数据块被称为报⽂段或段。

2. 校验和：TCP将保持它首部和数据的校验和。这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如果收到报文的校验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。

3. 序列号：TCP给每个数据包指定序列号，接收方根据序列号给数据包进行排序，并根据序列号对数据包去重。

4. 确认应答：通过ARQ协议实现。基本原理是每发完一个分组就停止发送，等待对方确认。如果没收到确认，会重发数据包。

5. 超时重传：当TCP发出一个数据段后，它启动一个定时器，如果不能及时收到⼀个确认，将重发这个报⽂段。

6. 流量控制：TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据量。当接收方来不及处理发送方的数据，能提示发送方降低发送速率，防止包丢失。TCP利用滑动窗口实现流量控制。

7. 拥塞控制：当网络拥塞时，减少数据的发送。

TCP粘包问题

IP

⽹络层（IP)与数据链路层(MAC)有什么关系

MAC：实现【直连】的两个设备之间通信。
IP：负责在【没有直连】的两个⽹络之间进⾏通信传输。

在⽹络数据包传输中，源IP地址和⽬标IP地址在传输过程中是不会变的，只有源MAC地址和⽬标MAC⼀直在变化。

IP地址分类

A、B、C类地址

概念

最⼤主机数=2^主机号位数-2，其中有两个地址，全0和全1是⽐较特殊的。主机号全为1指定某个网络下所有主机，用于广播；主机号全为0指定某个网络。

广播

⼴播地址⽤于在同⼀个链路中相互连接的主机之间发送数据包。⼴播地址可以分为本地⼴播和直接⼴播两种。

D、E类地址

概念

D 类和 E 类地址是没有主机号的，所以不可⽤于主机 IP，D 类常被⽤于多播，E 类是预留的分类，暂时未使⽤。


多播地址⽤于将包发送给特定组内的所有主机。由于⼴播⽆法穿透路由，若想给其他⽹段发送同样的包，就可以使⽤可以穿透路由的多播。

IP地址分类的优缺点

优点：
可以根据IP地址的前四位来判别IP地址属于哪个类别。简单明了，选路简单。

缺点：
同⼀⽹络下没有地址层次，⽐如⼀个公司⾥⽤了 B 类地址，但是可能需要根据⽣产环境、测试环境、开发环境来划分地址层次，⽽这种 IP 分类是没有地址层次划分的功能，所以这就缺少地址的灵活性。

A、B、C类有个尴尬处境，就是不能很好的与现实⽹络匹配。C 类地址能包含的最⼤主机数量实在太少了，只有 254 个，估计⼀个⽹吧都不够⽤。⽽ B 类地址能包含的最⼤主机数量⼜太多了，6 万多台机器放在⼀个⽹络下⾯，⼀般的企业基本达不到这个规模，闲着的地址就是浪费。这两个缺点，都可以在 CIDR ⽆分类地址解决。

CIDR无分类地址

这种⽅式不再有分类地址的概念，32 ⽐特的 IP 地址被划分为两部分，前⾯是⽹络号，后⾯是主机号。

如何划分网络号和主机

1. a.b.c.d/x
   表示形式 a.b.c.d/x ，其中 /x 表示前 x 位属于⽹络号， x 的范围是 0 ~ 32 ，这就使得 IP 地址更加具有灵活性。
   

2. ⼦⽹掩码
   掩码的意思就是掩盖掉主机号，剩余的就是⽹络号。将⼦⽹掩码和 IP 地址按位计算 AND，就可得到⽹络号。
   
   
   

为什么划分网络号和主机

因为两台计算机要通讯，⾸先要判断是否处于同⼀个⼴播域内，即⽹络地址是否相同。如果⽹络地址相同，表明接受⽅在本⽹络上，那么可以把数据包直接发送到⽬标主机。

路由器寻址⼯作中，也就是通过这样的⽅式来找到对应的⽹络号的，进⽽把数据包转发给对应的⽹络内。

如何划分子网

⼦⽹划分实际上是将主机地址分为两个部分：⼦⽹⽹络地址和⼦⽹主机地址。形式如下：

公有和私有IP地址

在A、B、C分类地址，实际⼜分公有IP地址和私有IP地址。
平时我们办公室、家⾥、学校⽤的 IP 地址，⼀般都是私有 IP 地址。因为这些地址允许组织内部的 IT ⼈员⾃⼰管理、⾃⼰分配，⽽且可以重复。
公有 IP 地址是有个组织统⼀分配的，假设你要开⼀个博客⽹站，那么你就需要去申请购买⼀个公有 IP，这 样全世界的⼈才能访问。并且公有 IP 地址基本上要在整个互联⽹范围内保持唯⼀。

IP地址与路由控制

IP地址的⽹络地址这⼀部分是⽤于进⾏路由控制。路由控制表中记录着⽹络地址与下⼀步应该发送⾄路由器的地址。在主机和路由器上都会有各⾃的路由器控制表。
在发送 IP 包时，⾸先要确定 IP 包⾸部中的⽬标地址，再从路由控制表中找到与该地址具有相同⽹络地址的记录，根据该记录将 IP 包转发给相应的下⼀个路由器。如果路由控制表中存在多条相同⽹络地址的记录，就选择相同位数最多的⽹络地址，也就是最⻓匹配。
举例说明：

环回地址

环回地址是不会流向⽹络：
环回地址是在同⼀台计算机上的程序之间进⾏⽹络通信时所使⽤的⼀个默认地址。 计算机使⽤⼀个特殊的 IP 地址 127.0.0.1 作为环回地址。
与该地址具有相同意义的是⼀个叫做 localhost 的主机名。使⽤这个 IP 或主机名时，数据包不会流向⽹络。

IPv6

IPv6亮点

• 可分配地址变多
• IPv6 可⾃动配置，即使没有 DHCP 服务器也可以实现⾃动分配IP地址，真是便捷到即插即⽤啊。
• IPv6 包头包⾸部⻓度采⽤固定的值 40 字节，去掉了包头校验和，简化了⾸部结构，减轻了路由器负荷，⼤⼤提⾼了传输的性能。
• IPv6 有应对伪造 IP 地址的⽹络安全功能以及防⽌线路窃听的功能，⼤⼤提升了安全性。
  
  

IPV6地址的标识⽅法

IPv4 地址⻓度共 32 位，是以每 8 位作为⼀组，并⽤点分⼗进制的表示⽅式。
IPv6 地址⻓度是 128 位，是以每 16 位作为⼀组，每组⽤冒号 「:」 隔开。

如果出现连续的 0 时还可以将这些 0 省略，并⽤两个冒号 「::」隔开。但是，⼀个 IP 地址中只允许出现⼀次两个
连续的冒号。

IPv6和IPv4首部差别

IPV6相⽐IPV4的⾸部改进

• 取消了⾸部校验和字段：因为在数据链路层和传输层都会校验，因此 IPv6 直接取消了 IP 的校验。
• 取消了分⽚/重新组装相关字段：分⽚与重组是耗时的过程，IPv6 不允许在中间路由器进⾏分⽚与重组，这 种操作只能在源与⽬标主机，这将⼤⼤提⾼了路由器转发的速度。
• 取消选项字段：选项字段不再是标准 IP ⾸部的⼀部分了，但它并没有消失，⽽是可能出现在 IPv6 ⾸部中的 「下⼀个⾸部」指出的位置上。删除该选项字段使的 IPv6 的⾸部成为固定⻓度的 40 字节。

ARP与RARP协议

ARP

在传输⼀个 IP 数据报的时候，确定了源 IP 地址和⽬标 IP 地址后，就会通过主机「路由表」确定 IP 数据包下⼀ 跳。然⽽，⽹络层的下⼀层是数据链路层，所以我们还要知道「下⼀跳」的 MAC 地址。 由于主机的路由表中可以找到下⼀跳的 IP 地址，所以可以通过 ARP 协议（Address Resolution Protocol，地址解析协议），求得下⼀跳的 MAC 地址。

ARP是如何知道对⽅的MAC地址的呢？ARP 是借助** ARP 请求与 ARP 响应**两种类型的包确定 MAC 地址的。

主机会通过⼴播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包⾥的内容，如果 ARP 请求包中的⽬标 IP 地址与⾃⼰的 IP 地址⼀致，那么这个设备就将⾃⼰的 MAC 地址塞⼊ ARP 响应包返回给主机。

操作系统通常会把第⼀次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地址的 MAC 地址。 不过，MAC 地址的缓存是有⼀定期限的，超过这个期限，缓存的内容将被清除。

RARP

ARP 协议是已知 IP 地址求 MAC 地址，那 RARP 协议正好相反，它是已知 MAC 地址求 IP 地址。
例如将打印机服务器等⼩型嵌⼊式设备接⼊到⽹络时就经常会⽤得到。通常这需要架设⼀台 RARP 服务器，在这个服务器上注册设备的 MAC 地址及其 IP 地址。然后再将这个设备接⼊到⽹络。

DHCP

概念

DHCP(Dynamic Host Configuration Protocol,动态主机配置协议)。我们的电脑通常都是通过 DHCP 动态获取 IP 地址，⼤⼤省去了配 IP 信息繁琐的过程。

主机如何动态获取IP

DHCP 客户端进程监听的是 68 端⼝号，DHCP 服务端进程监听的是 67 端⼝号。

DHCP 中继代理

⽤的是⼴播，那如果 DHCP 服务器和客户端不是在同⼀个局域⽹内，路由器⼜不会转发⼴播包，那不是每个⽹络都要配⼀个 DHCP 服务器？为了解决这⼀问题，就出现了 DHCP 中继代理。有了 DHCP 中继代理以后，对不同⽹段的 IP 地址分配也 可以由⼀个 DHCP 服务器统⼀进⾏管理。

DHCP 客户端会向 DHCP 中继代理发送 DHCP 请求包，⽽ DHCP 中继代理在收到这个⼴播包以后，再以单播的形式发给 DHCP 服务器。服务器端收到该包以后再向 DHCP 中继代理返回应答，并由 DHCP 中继代理将此包⼴播给 DHCP 客户端 。

NAT

来由

IPv4 的地址是⾮常紧缺的，在前⾯我们也提到可以通过⽆分类地址来减缓 IPv4 地址耗尽的速度，但是互联⽹的⽤户增速是⾮常惊⼈的，所以 IPv4 地址依然有被耗尽的危险。
于是，提出了⼀种⽹络地址转换 NAT ( Network Address Translation, ⽹络地址转换)的⽅法，再次缓解了 IPv4 地址耗尽的问题。 简单的来说 NAT 就是同个公司、家庭、教室内的主机对外部通信时，把私有 IP 地址转换成公有 IP 地址。

原理

图中有两个客户端 192.168.1.10 和 192.168.1.11 同时与服务器 183.232.231.172 进⾏通信，并且这两个客户端的本地端⼝都是 1025。 此时，两个私有 IP 地址都转换 IP 地址为公有地址 120.229.175.121，但是以不同的端⼝号作为区分。
于是，⽣成⼀个 NAPT 路由器的转换表，就可以正确地转换地址跟端⼝的组合，令客户端 A、B 能同时与服务器之 间进⾏通信。 这种转换表在 NAT 路由器上⾃动⽣成。例如，在 TCP 的情况下，建⽴ TCP 连接⾸次握⼿时的 SYN 包⼀经发出， 就会⽣成这个表。⽽后⼜随着收到关闭连接时发出 FIN 包的确认应答从表中被删除。

缺点

由于 NAT/NAPT 都依赖于⾃⼰的转换表，因此会有以下的问题：
外部⽆法主动与 NAT 内部服务器建⽴连接，因为 NAPT 转换表没有转换记录。
转换表的⽣成与转换操作都会产⽣性能开销。
通信过程中，如果 NAT 路由器重启了，所有的 TCP 连接都将被重置。

ICMP

来由

ICMP（ Internet Control Message Protocol，也就是互联⽹控制报⽂协议）。
⽹络包在复杂的⽹络传输环境⾥，常常会遇到各种问题。 当遇到问题的时候，总不能死个不明不⽩，没头没脑的作⻛不是计算机⽹络的⻛格。所以需要传出消息，报告遇到 了什么问题，这样才可以调整传输策略，以此来控制整个局⾯。

功能

主要功能包括：确认 IP 包是否成功送达⽬标地址、报告发送过程中 IP 包被废弃的原因和改善⽹络设置等。
在 IP 通信中如果某个 IP 包因为某种原因未能达到⽬标地址，那么这个具体的原因将由 ICMP 负责通知。

类型

ICMP⼤致可以分为两⼤类：
⼀类是⽤于诊断的查询消息，也就是「查询报⽂类型」
⼀类是通知出错原因的错误消息，也就是「差错报⽂类型

在浏览器中输⼊URL并按下回⻋之后会发⽣什么