• 应用层：是应用程序及其应用层协议存在的地方。应用层协议主要有：HTTP协议、SMTP协议、FTP协议、DNS协议。
  HTTP：提供了Web文档的请求和传送。
  SMTP：提供了电子邮件报文的传输。
        报文(message)：位于应用层的信息分组(数据)称为报文。
  FTP：提供了两个端系统之间的文件传送。
  DNS：⽤来进行域名和IP地址间的转换。
  
  
  
  
  
• 传输层(运输层)：网络的运输层在应用程序端点之间传送应用层报文。两种运输协议：TCP协议和UDP协议。
  TCP：面向连接的服务。确保传递和流量控制。
  UDP：面向无连接的服务。无可靠性，无流量控制和拥塞控制。
  
  
• 网络层(IP层)：负责将数据包从一台主机移动到另一台主机。网络层协议：IP协议、路由选择协议。
  IP协议：定义了数据包中的各字段及端系统和路由器如何使用作用于这些字段。
  路由选择协议：决定数据包的路由。
  
  
• 网络接口层：网络接口层包括数据链路层和物理层，是TCP/IP与各种LAN(局域网)或WAN(广域网)的接口。协议？

• 表示层为在应用程序之间传送的信息提供表示方法的服务，它只关心信息发出的语法和语义，处理所有与数据表示及运输有关的问题，包括转换、加密和压缩。
• 会话层建立在传输层之上，利用传输层提供的服务，使应用程序建立和维持会话，并使会话获得同步，包括了建立校验点和恢复通信的方法。

• 简单：
  HTTP的基本报文格式为header+body(请求头请求体、响应头响应体)，头部信息也是key-value的简单文本形式，易于理解。
  
• ★灵活和易于扩展：
  HTTP协议⾥的各种请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充；
  同时HTTP⼯作在应⽤层（OSI第七层），它的下层可以随意变化：比如HTTPS就是在HTTP与TCP之间增加了SSL/TSL安全传输层，HTTP/3(https://view.inews..com/a/A02BPE00)把TCP换成了基于UDP的QUIC。
  
  
  
  

• 无状态、明文传输、不安全：
  无状态(双刃剑)：无状态指的是服务器不会去记忆HTTP的状态(不保存关于客户端的任何信息)，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，但在完成有关联性的操作时会非常麻烦。
      例如登录->添加购物车->下单支付等一系列操作都要知道用户的身份，但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。
  【对于无状态的解法方案】可以用 Cookie 技术。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
  
          
  明文传输(双刃剑)：传输过程中的信息方便阅读，通过浏览器的F12控制台(或Wireshark抓包)都可以直接⾁眼查看，但这种信息透明容易导致信息被窃取。  
  不安全(纯纯的缺点)：
          使用明文通信，因此内容可能被窃听
          不验证通信方的身份，因此可能遭遇伪装
          无法证明报文的完整性，因此信息可能已被篡改
  可以⽤ HTTPS 的⽅式解决，也就是通过引⼊ SSL/TLS 层，使其变得安全。
  
  
  
  
  
  
  
  
  
  
  

• HTTP请求报文：主要由请求行、请求头、请求体构成。
      
  
  • 请求行有三个字段：请求方法、URL、HTTP版本号，如：POST /chapter17/user.html HTTP/1.1
    
    
  • 请求头包含请求的附加信息，以键值对的形式组成。
    ①Host字段：客户端发送请求时，用来指定服务器的域名。
        
    ②Connection 字段：常用于客户端要求服务器使用「 HTTP 长连接」机制，以便其他请求复用。
        
    ③Accept 字段：客户端声明自己可以接受哪些数据格式。
    
    
    
    
    
    
    
  • 请求体包含多个请求参数的数据。含回⻋、换行和请求数据（并⾮都有）
  
  
  
• HTTP响应报文：主要由响应行、响应头、响应体构成。
      
  
  • 响应行有三个字段：HTTP协议版本号、状态码、状态码描述，如：HTTP/1.1 200  OK
    
    ★五大HTTP状态码：
            
    常见状态码及描述：
            200：客户端请求成功
            206：partial content 服务器已经正确处理部分GET请求，实现断点续传或同时分⽚下载，该请求必须包含Range 请求头来指示客户端期望得到的范围
            301（永久重定向）：说明请求的资源已经不存在了，需要用新的URL再次访问。(该资源已被永久移动到新位置，将来任何对该资源的访问都要使用本响应返回的若干个URL 之一。)
            302（临时重定向）：说明请求的资源还在，但暂时需要用另一个 URL 来访问。(请求的资源现在临时从不同的URI中获得。)
    【tips】301 和 302 都会在响应头里使用 Location 字段，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。
            304：如果客户端发送⼀个待条件的GET请求并且该请求以经被允许，而文档内容未被改变，则返回304，该响应不 包含包体（即可直接使用缓存）
            400：表示客户端请求的报文有错误，但只是个笼统的错误码
            401：请求需要认证
            403：请求的对应资源禁止被访问，并不是客户端的请求出错
            404：表示请求的资源在服务器上不存在或未找到
            500：与 400 类似，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道
    
            502：通常是服务器作为网关或代理时返回的错误码，表示服务器访问后端服务器发生了错误
            503：表示服务器正忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  • 响应头、响应体与请求头、请求体的作用类似。
    ①Content-Length 字段：表明本次响应的数据长度。
    
        
    ②Content-Type 字段：用于服务器回应时，告诉客户端，响应数据是什么格式。
    
    
    
    
  
  
  

• 首先在浏览器地址栏中输入页面的URL；
• 浏览器依次在浏览器缓存→操作系统缓存→路由器缓存中寻找匹配的URL，若有则直接显示页⾯内容；
• 若没有，浏览器将发送HTTP请求，在发送请求之前，浏览器需要先进行域名解析(即DNS解析)，获取相应的IP地址；
• 获取到IP地址后，浏览器向服务器发起TCP连接，与服务器建立TCP三次握手；
• 握手成功后，浏览器向服务器发送HTTP请求，来请求服务器端的数据；
• 服务器处理请求，将数据返回给浏览器；
• 浏览器收到HTTP响应，查询状态，状态不成功则弹出相应提示；状态成功则读取页面内容、进⾏浏览器渲染、解析HTML源码进行页面展示；
• 关闭TCP连接（四次挥⼿）

• GET：申请获取资源，不对服务器产⽣影响
• POST：客户端向服务器提交数据，会影响服务器，服务器可能动态创建新的资源或更新原有资源
• HEAD：类似GET，仅要求服务器返回头部信息
• PUT：上传某个资源
• DELETE：删除某个资源
• TRACE：用于测试，要求目标服务器返回原始的HTTP请求内容
• CONNECT：用于代理服务器
• OPTION：查询服务器对特定URL支持的请求方法

• 概念上：GET请求是客户端从服务器获取指定资源，不会对服务器产生影响；POST请求是客户端向服务器提交数据，会影响服务器，服务器可能动态创建新的资源或更新原有资源。
• 请求参数上：GET通过URL携带请求参数，由于浏览器对 URL⼀般都有长度限制（HTTP协议本身对 URL长度并没有做任何规定），所以请求参数也有长度限制；POST的请求参数是位于请求体中，没有长度限制。
• 缓存上：GET会被浏览器主动缓存(如果下⼀次传输的数据相同，就会直接返回缓存中的内容，以求更快的展示数据)；POST请求不会被缓存。
• 安全幂等性上：GET是安全幂等的(因为它只进行读操作，⽆论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的)；POST是不安全且不幂等的(因为是新增或者提交数据的操作，所以会修改服务器上的资源，且多次提交数据就会创建多个资源)
  【补充】 ①安全：HTTP协议中，安全是指请求⽅法不会破坏服务器上的资源；
                ②幂等：多次执⾏相同的操作，结果都相同。
  
  
  
  
• ★TCP数据包数量上：GET方法只产生一个TCP数据包，浏览器会把请求头和请求数据⼀起发送出去，服务器响应200 ok（返回数据）；POST会产生两个TCP数据包，浏览器会先将请求头发送给服务器，待服务器响应100 continue，浏览器再发送请求数据，服务器响应200 ok（返回数据）。
  
  

• SSL：Secure Socket Layer，安全套接字协议
• TLS：Transport Layer Security，安全传输层协议
• HTTPS(Hyper Text Transfer Protocol Secure)：超⽂本安全传输协议，HTTPS = HTTP + SSL/TLS安全协议

• 优点：
  • 信息加密：在数据传输过程中，使⽤秘钥加密，安全性更高
  • 校验机制：无法篡改通信的内容，篡改了就不能正常显示
  • 身份证书：证明报文的完整
• 缺点：
  • 需要加解密计算，占⽤CPU资源，需要服务器配置或数目大
    
    
  • 握手阶段延时较高：在会话前还需进行SSL握手
  • 部署成本⾼：需要购买CA证书

        

<div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 数字签名只能由私钥拥有者生成，但是私钥拥有者不一定是请求的那个客户端，其他人也可生成一套公钥私钥进行数字签名来冒充请求客户端。这个问题可以通过数字证书来解决。 </div> <div> <ul> <li> 服务器把自己的公钥注册到CA机构，<strong>CA机构用自己的私钥将服务器的公钥进行数字签名并颁发数字证书</strong>；<br /> 

“CA机构用自己的私钥进行数字签名”：客户端可以用CA的公钥对CA的身份进行确认，确保证书的合法性。

讯享网 </li> <li> 客户端向服务器发送HTTPS请求，服务器将<strong>数字证书</strong>(服务器公钥+CA数字签名)返回给客户端； </li> <li> 客户端拿到证书后使用CA的公钥(已事先嵌入客户端或系统中)对证书进行确认； </li> <li> 如果确认证书是可信的就从证书中获取服务器公钥，<strong>使用服务器公钥对传输内容进行加密</strong>后发送给服务器；<br /> 

“客户端使用服务器公钥对内容进行加密”：因为这些内容只能给服务器看，所以用服务器公钥进行加密，只有服务器自己的私钥才能对内容解密。

 </li> <li> 服务器用自己的私钥对内容进行解密。 </li> </ul> 

        

讯享网</div> <div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; HTTPS通过TCP三次握手建立连接后，还需要进行SSL/TLS握手才能进行通信。<br /> </div> <div> <ul> <li> 通信双方经过三次握手建立TCP连接后，客户端<span style="color:#000000;">向服务器发起加密通信请求(即ClientHello<span style="color:#2C3E50;">请求</span>)，客户端主要向服务器发送以下信息：<br /> 

    ①客户端支持的 TLS 协议版本，如 TLS 1.2 版本；
    ②客户端生成的随机数（Client Random），后面用于生成「会话秘钥」条件之一；

 <div style="color:#2C3E50;"> <span style="color:#000000;">&nbsp;&nbsp;&nbsp;&nbsp;③客户端<strong>支持的密码套件列表</strong>，如 RSA 加密算法。</span> </div> 

讯享网 </li> <li> <div style="color:#2C3E50;"> <span style="color:#000000;">服务器收到请求后，向客户端发出响应(即SeverHello)，响应信息有如下内容：<br /> 

    ①确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信；
    ②服务器生成的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一；
    ③确认的密码套件列表，如 RSA 加密算法；
    ④服务器的数字证书。

 </div> </li> <li> <div style="color:#2C3E50;"> <span style="color:#000000;">客户端收到响应后，通过浏览器或者操作系统中的 <strong>CA 公钥</strong>，确认服务器的数字证书的真实性。 如果证书可信，客户端从证书中取出服务器的公钥，用它加密报文，再向服务器发送如下信息：<br /> 

    ①一个随机数（pre-master key），该随机数会被服务器公钥加密；
    ②加密通信算法改变通知，表示后续信息都将用「会话秘钥」进行加密通信；
    ③客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key）后就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

讯享网 </div> </li> <li> <div style="color:#2C3E50;"> <span style="color:#000000;">服务器收到第三个随机数后，通过协商的加密算法，计算出「会话秘钥」，然后向客户端发送最后的信息：<br /> 

    ①加密通信算法改变通知，表示后续信息都将用「会话秘钥」进行加密通信；
    ②服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此整个 TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

 </div> </li> </ul> </div> <div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 【场景假设】客户端通过浏览器向服务端发起 HTTPS 请求时，被<strong>「假基站」</strong>转发到了一个<strong>「中间人服务器」</strong>，于是<strong>客户端是和「中间人服务器」完成了 TLS 握手，然后这个「中间人服务器」再与真正的服务端完成 TLS 握手</strong>。 </div> <div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 【分析】从客户端的角度来看，其实<strong>并不知道网络中存在中间人服务器这个角色</strong>。那么中间人<strong>就可以解开浏览器发起的 HTTPS 请求里的数据，也可以解开服务端响应给浏览器的 HTTPS 响应数据</strong>，也就是说中间人能够 “偷看” 浏览器与服务端之间的 HTTPS 请求和响应的数据。 </div> <div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;但是这种情况的发生是有前提条件的，前提是<strong>需要用户接受了中间人服务器的证书</strong>。中间人服务器与客户端在 TLS 握手过程中，实际上<strong>发送了自己伪造的证书给浏览器</strong>，而<strong>这个伪造的证书是能被浏览器（客户端）识别出是非法的</strong>，于是就<strong>会提醒用户该证书存在问题(如下图)</strong>。如果用户还是选择接受中间人伪造的证书，那么后续整个 HTTPS 通信都能被中间人监听了。所以，这其实并不能说 HTTPS 不够安全，毕竟浏览器都已经提示证书有问题了，如果用户坚决要访问，那不能怪 HTTPS。另外，如果用户的客户端中病毒了，<strong>被恶意导入了中间人的根证书</strong><strong>，那么在验证中间人证书的时候，就会认为他的证书是合法的</strong>，这种情况下，浏览器是不会弹出证书存在问题的风险提醒的。 这其实也不关 HTTPS 的事情，是你<strong>电脑中毒了</strong>才导致 HTTPS 数据被中间人劫持的。&nbsp; </div> <div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp; 因此<strong>就 HTTPS 协议本身而言它是安全可靠的</strong>，即使你成功进行中间人攻击，<strong>本质上是利用了客户端的漏洞</strong>（用户点击继续访问或者被恶意导入伪造的根证书），<strong>并不是 HTTPS 不够安全</strong>。 </div> <div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<img src="https://uploadfiles.nowcoder.com/images//_28/0310B241B344CD19CE" alt="" width="400" height="247" title="" align="" /> </div> 

• DNS(Domain Name System)协议⽤来进行域名和IP地址间的转换
• DNS：⾯向⽤户 IP：⾯向主机
• 域名服务主要是基于UDP实现的，服务器端⼝号为53
  
  
• 三种类型的DNS服务器：根域名DNS服务器、顶级域名DNS服务器、权威域名DNS服务器
  
  

• ① 找浏览器缓存：浏览器检查浏览器自身DNS缓存中是否有域名对应的DNS缓存，如果有的话返回对应的ip地址；
• ② 找系统缓存：如果没有的话，查看系统的hosts文件（C:WindowsSystem32driversetc）是否有域名对应的IP地址，有则返回；
  【补充】hosts文件用于将常用的域名与对应IP地址建立关联，相当于本地的一个DNS服务。
  
  
  
• ③路由器缓存： 如果没有的话，浏览器发起DNS系统调用，向本地配置的首选DNS服务器发起域名解析请求（即通过UDP协议，向DNS的53端口发起请求）
  • 请求先在运营商DNS服务器(本地服务器)上进行请求，如果找到对应的没有过期的条目，则解析成功；
  • 如果没有找到，运营商DNS服务器根据请求进行迭代查询：
    • 首先向根域名DNS服务器发送请求，服务器收到请求后，根据域名返回对应的顶级域名DNS服务器的IP地址，并返回给运营商DNS服务器；
    • 然后运营商DNS服务器收到返回的顶级域名服务器IP地址后，向顶级域名服务器发送请求，顶级域名服务器收到请求后，根据域名返回对应的权威域名DNS服务器的IP地址，并返回给运营商DNS服务器；
    • 运营商DNS服务器收到返回的权威域名服务器IP地址后，向权威域名服务器发送请求，权威域名服务器将目标ip地址返回给运营商DNS服务器；
    • 最后运营商DNS服务器将目标ip地址返回给请求的主机，DNS解析完成

讯享网<div> <ul> <li> <b>递归查询<br /> 

DNS 服务器接收到DNS客户端的请求，将请求的资源响应给客户端；如果无法找到请求资源记录，则返回错误消息。
在递归查询模式下，用户主机和本地DNS服务器都是只发送一次请求：
    用户主机→本地DNS服务器→根域名DNS服务器→顶级域名DNS服务器→权威域名DNS服务器→得到映射结果
    用户主机←本地DNS服务器←根域名DNS服务器←顶级域名DNS服务器←权威域名DNS服务器←映射结果

 </li> <li> <strong>迭代查询</strong><br /> 

DNS 服务器收到DNS客户端请求后，不会直接返回查询结果，而是告诉客户端另一台DNS 服务器地址，客户端再向这台 DNS 服务器发送请求，依次循环直到返回查询结果或发生错误或超时为止。
在迭代查询模式下，用户主机只发送一次请求，本地DNS服务发送不少于一次请求：

    本地DNS服务器→根域名DNS服务器，根域名DNS服务器→(顶级域名DNS服务器的IP地址)→本地DNS服务器；
    本地DNS服务器→顶级域名DNS服务器，顶级域名DNS服务器→(权威域名DNS服务器的IP地址)→本地DNS服务器；
    本地DNS服务器→权威域名DNS客户端，权威域名DNS服务器→(能够解析的查询结果)→本地DNS服务器；
    本地DNS服务器→(目标ip地址)→客户端

讯享网 </li> <li> <strong>非递归查询</strong><br /> 

当请求主机查询 DNS 服务器来获取DNS服务器有权访问的记录时通常会进⾏此查询，因为DNS服务器对该记录具有权威性，或者该记录存在于其缓存内。

 </li> </ul> </div> 

讯享网&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; cookie和session都是用来<strong>缓存用户信息</strong>的。<br /> 

<strong>（1）cookie</strong><br /> 

讯享网<strong>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 1）作用<br /> 

        在第⼀次登录服务器后，服务器会返回⼀些数据（cookie）给浏览器。浏览器将这些数据保存在本地，当浏览器再次发送请求时，会自动把上⼀次请求存储的cookie发送给服务器。服务器可以通过这些数据来判断用户。 

讯享网<strong>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2）特点</strong> 

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;可存储的数据量有限，⼀般不会超过<strong>4KB</strong>。<br /> 

讯享网<strong>（2）session</strong> 

<strong>&nbsp;&nbsp;&nbsp;&nbsp;</strong><strong>&nbsp; &nbsp; 1）session与cookie的区别</strong><br /> 

讯享网&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;cookie是存储在本地浏览器，而session存储在服务器。<br /> 

        2）优缺点

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 优点：数据存储在服务器<strong>更加安全</strong>； 

讯享网&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 缺点：将数据存储在服务器<strong>占用了服务器资源</strong>。 

• 连接：TCP是面向连接的，在传输前需要进行三次握手建立连接；UDP是面向无连接的，不需要三次握手建立连接，立刻传输数据。
• 服务形式：TCP只能一对一提供服务(只能一个客户端与一个服务器建立连接)，UDP支持一对一、一对多、多对一、多对多的通信。
• 可靠性：TCP保证了数据的可靠交付，使数据无差错、不重复、不丢失、按序到达； UDP是尽可能交付，不保证可靠性。
• 连接控制机制：TCP拥有流量控制、拥塞控制，保证传输安全性；UDP在网络拥堵情况下也不会降低发送速率。
• 传输方式：TCP基于字节流，没有边界，但是保证传输顺序和可靠性；UDP继承了IP层特性，基于报文，有边界，可能出现乱序和丢包。
  【字节流】不包含边界数据的连续流。
  
• 首部大小：TCP首部长度在不使用选项字段时是20字节，使用选项字段长度增加(可变)；UDP首部固定8字节。
• 分片方式：当TCP数据大于接收方MSS(最大报文长度)时，会在传输层对数据进行分片和重组，如果有某个分片丢失，则只需要重传丢失的分片；当UDP数据大于MTU(最大传输单元)时会在网络层对数据进行分片和重组，再传给传输层，如果某个分片丢失，则需要重传所有分片，开销大。
  （有关二者分片的详细内容：https://www.cnblogs.com/yanchengwang/p/5919676.html）
  （如何理解TCP面向字节流、UDP面向报文？——https://blog.csdn.net/_/article/details/）
  
  

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

• FTP 文件传输
• HTTP / HTTPS

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

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

• UDP报文段结构
  
  UDP首部只有四个字段，每个字段由两字节(16bit)组成。
  
  目标端口和源端口： 告诉 UDP 协议应该把报⽂发给哪个进程。
  包长度： 保存了 UDP ⾸部的⻓度跟数据的⻓度之和。
  校验和： 为了提供可靠的 UDP ⾸部和数据⽽设计，接收⽅使⽤检验和来检查该报⽂段中是否出现差错。
  
  
  
  
• TCP报文段结构
  
  TCP报文段的首部一般是20字节(选项部分可选，不在20字节里)，有与UDP一样的四个字段(红框部分)。
  
  源端⼝号和⽬的端⼝号： ⽤于多路复⽤/分解来⾃或送到上层应⽤的数据。告诉主机报⽂段来⾃哪⾥，该传给哪个上层协议或应⽤程序。
  32bit序列号： 该报文段第一个字节的字节流编号，⽤来解决网络包乱序问题。
  32bit确认应答号：对发送来的 TCP 报文段的响应，★值是收到的 TCP 报文段的序号值加1，⽤来解决不丢包的问题。
          序列号和确认应答号都用于实现可靠数据传输。
  4bit首部长度：表示 TCP 的首部有多少字节。由于选项字段的存在，TCP首部长度是可变的，通常选项字段为空，所以首部的典型长度是20字节，最长是60字节。
  接收窗口：告诉对⽅本端TCP缓冲区还有多少空间可以接收数据，⽤来做流量控制。
  6bit的标志字段：
          ACK：用于指示确认应答(acknowledge)号的值是否有效，1表示包含对已成功接收报文段的确认；
          RST：用于重置(reset)⼀个已经混乱的连接，或拒绝⼀个无效的数据段或者连接请求；
          SYN：用于连接建立过程，1表示请求建立⼀个连接；
          FIN：finish，用于断开连接，1表示发送方没有数据要传输了，希望断开连接。
  检验和：接收方使⽤检验和来检查该报⽂段是否出现差错（CRC算法），同 UDP。
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• 选项字段可以有三个字段：kind、length、info：
  • kind：说明选项类型，有的TCP选项没有后⾯两个字段，仅包含1字节的kind字段。
  • length：(如果有的话)指定该选项的总长度。该长度包括kind字段和length字段占据的2字节。
  • info：(如果有的话)表示选项的具体信息。
• 常见的TCP选项类型有7种：
  
  • kind=0，选项表结束（EOP）选项。
    ⼀个报⽂段仅⽤⼀次，放在末尾⽤于填充，⽤来说明首部已经没有更多的消息，应用数据在下⼀个32位开始处。
    
  • kind=1，空操作（NOP）选项。
    没有特殊含义，⼀般用于将TCP选项的总长度填充为4字节的整数倍。
    
  • kind=2，最大报文长度（MSS）选项。
    TCP连接初始化时，通信双⽅使⽤该选项来协商最⼤报⽂段⻓度。TCP模块通常将MSS设置为 MTU - 40 字节（减掉的这40字节包括20字节的TCP头部和20字节的IP头部）。
    这样携带TCP报⽂段的IP数据报的⻓度就不会超过MTU（假设TCP头部和IP头部都不包含选项字段，并且这也是⼀般情况），从⽽避免本机发⽣IP分⽚。对以太⽹⽽⾔，MSS值是1460（1500-40）字节。
    
    
  • kind=3，窗口扩大因子选项。
    TCP连接初始化时，通信双⽅使⽤该选项来协商接收窗⼝的扩大因子。在TCP的头部中，接收窗⼝⼤⼩是⽤16位表示的，故最⼤为65535字节，但实际上TCP模块允许的接收窗⼝⼤⼩远不⽌这个数（为了提⾼TCP通信的吞吐
    量）。窗⼝扩⼤因⼦解决了这个问题。
    假设 TCP 头部中的接收通告窗⼝⼤⼩是 N，窗⼝扩⼤因⼦（移位数）是 M，那么 TCP 报⽂段的实际接收通告窗⼝⼤⼩是 N*2M，或者说 N 左移 M 位。注意，M的取值范围是 0～14。和 MSS 选项⼀样，窗⼝扩⼤因⼦选项只能出现在同步报⽂段中，否则将被忽略。但同步报⽂段本身不执⾏窗⼝扩⼤操作，即同步报⽂段头部的接收窗⼝⼤⼩就是该 TCP 报⽂段的实际接收窗⼝⼤⼩。当连接建⽴好之后，每个数据传输⽅向的窗⼝扩⼤因⼦就固定不变了。
    
    
    
  • kind=4，选择性确认（Selective Acknowledgment，SACK）选项。
    选择性确认选项⽤在连接初始化时，表示是否⽀持 SACK 技术。SACK 技术使 TCP 只需要重新发送丢失的 TCP 报⽂段，⽽不⽤发送所有未被确认的 TCP 报⽂段。
    TCP 通信时，如果某个 TCP 报⽂段丢失，则 TCP 会重传最后被确认的 TCP 报⽂段后续的所有报⽂段，这样原先已经正确传输的 TCP 报⽂段也可能重复发送，从⽽降低了 TCP 性能。
    
    
  • kind=5，SACK实际⼯作的选项。
    该选项的参数告诉发送⽅本端已经收到并缓存的不连续的数据块，从⽽让发送端可以据此检查并重发丢失的数据块。
    每个块边沿（edge of block）参数包含⼀个4字节的序号。其中块左边沿表示不连续块的第⼀个数据的序号，⽽块右边沿则表示不连续块的最后⼀个数据的序号的下⼀个序号。这样⼀对参数（块左边沿和块右边沿）之间的数据是没有收到的。因为⼀个块信息占⽤8字节，所以 TCP 头部选项中实际上最多可以包含4个这样的不连续数据块（考虑选项类型和⻓度占⽤的2字节）。
    
    
  • kind=8，时间戳选项。
    该选项提供了较为准确的计算通信双方之间的往返时间（Round Trip Time，RTT）的方法，为TCP流量控制提供信息。
    【补充】往返时间RTT：表示发送方发出最后一个数据到收到最后一个确认信号的时间。
    
    
    
    
    
    
  
  

• 文件描述符限制：每个 TCP 连接都是一个文件，如果文件描述符被占满了，会发生 too many open files。
      Linux 对可打开的文件描述符的数量分别作了三个方面的限制：
  
  • 系统级：当前系统可打开的最大数量，通过 cat /proc/sys/fs/file-max 查看；
  • 用户级：指定用户可打开的最大数量，通过 cat /etc/security/limits.conf 查看；
  • 进程级：单个进程可打开的最大数量，通过 cat /proc/sys/fs/nr_open 查看；
• 内存限制：每个 TCP 连接都要占用一定内存，操作系统的内存是有限的，如果内存资源被占满后，会发生 OOM(Out of Memory，内存溢出) 。

• #1 是已发送并收到 ACK确认的数据：1到31 字节
• #2 是已发送但未收到 ACK确认的数据：32到45 字节
• #3 是未发送但总大小在接收⽅处理范围内（接收⽅还有空间）：46到51字节
• #4 是未发送但总大小超过接收⽅处理范围（接收⽅没有空间）：52字节以后
  
  

• 滑动窗口内数据全部发送后，可用窗口为0，但在没收到ACK确认之前⽆法继续发送数据。

• 在收到32~36的ACK确认后，如果滑动窗口大小不变的话，滑动窗口向后移动5个字节，52-56变成可用窗口，可以继续发送数据。
  
  

• SND.WND ：表示发送窗口的大小（大小是由接收方指定的）
• SND.UNA ：代表Send Unacknowledged(未被接受的)指针，是一个绝对指针，指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节
• SND.NXT ：代表Send Next指针，也是一个绝对指针，指向未发送但可发送范围的第一个字节的序列号(即下一个要发送的)，也就是 #3 的第一个字节。
• 指向 #4 的第一个字节是个相对指针，需要 SND.UNA 指针加上 SND.WND 大小的偏移量，就可以指向#4 的第一个字节了( 32 + 20 = 52 )。
  那么可用窗口大小就是：
  可用窗口大小 = SND.WND - （ SND.NXT - SND.UNA ）
  
  
  
  

• #1 + #2 是已成功接收并确认的数据（等待应用进程读取）；
• #3 是未收到数据但可以接收的数据；
• #4 是未收到数据还不可以接收的数据；
  
  

• RCV.WND：表示接收窗口的大小，它会通告给发送方。
• RCV.NXT：是一个绝对指针，指向期望收到的下一个数据字节的序列号，也就是 #3 的第一个字节。
• 指向 #4 的第一个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND 大小的偏移量，就可以指向#4 的第一个字节了。

• 拥塞窗口cwnd是发送方维护的⼀个状态变量，根据⽹络拥塞程度⽽变化。
• 发送窗口大小等于拥塞窗口和接收窗口中的最小值，即swnd = min(cwnd, rwnd)。
• 如果网络中没有出现拥塞，cwnd增⼤；出现拥塞，cwnd减⼩。
  
  

• 只要发送方没有在规定时间内接收到 ACK 应答报⽂，也就是发生了超时重传，就会认为⽹络出现了拥塞。

• 连接建立完成后，初始化 cwnd = 1 ，表示可以传⼀个 MSS 大小的数据；
• 当收到⼀个 ACK 确认应答后，cwnd 增加 1，于是下⼀次能够发送 2 个；
• 当收到 2 个 ACK 确认应答后，cwnd 增加 2，于是就可以比之前多发2 个，所以下⼀次能够发送 4 个；
• 当收到 4 个 ACK 确认应答后，cwnd 增加 4，于是就可以比之前多发4 个，所以下⼀次能够发送 8 个。
  
  

• 有⼀个叫慢启动门限 ssthresh (slow start threshold—阈值、门限）状态变量。
  当 cwnd < ssthresh 时，使用慢启动算法。
  当 cwnd >= ssthresh 时，使用拥塞避免算法。
  
  

• 超时重传
• 快速重传

• ssthresh = cwnd
• cwnd = cwnd/2

• cwnd = ssthresh + 3 (3 的意思是确认有 3 个数据包被收到了) ；
• 重传丢失的数据包；
• 如果再收到重复的 ACK，那么 cwnd 增加 1；
• 如果收到新数据的 ACK 后，把 cwnd 设置为第⼀步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从重复的 ACK 开始时的数据都已收到，快恢复过程已经结束，可以回到快恢复之前的状态了，即再次进入拥塞避免状态(每当收到⼀个 ACK 时，cwnd 增加 1/cwnd)；

• 一开始，客户端和服务器都处于Close状态，先是服务器主动监听某个端口，处于Listen状态。
  • client_isn：客户端初始化序列号
  • server_isn：服务端初始化序列号
    【tips】图中的Seq Num是sequence number的缩写，代表序列号的意思。
    
• 第一次握手：客户端发起第一个报文——SYN报文：
    
  客户端会随机初始化序列号client_isn，将此序号放在TCP首部序列号字段中，同时把SYN标志位置为1，表示SYN报文。接着把SYN报文发生给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN_SENT状态。
  
  
• 第二次握手：服务端发起第二个报文——SYN+ACK报文：
  
  服务端收到 SYN 报文后，服务端先随机初始化自己的序列号server_isn，将此序号放在TCP 首部序列号字段中，然后把收到的 client_isn + 1 后填入确认应答号字段，接着把 SYN 和 ACK 标志位置为 1，最后把SYN+ACK报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
  
  
• 第三次握手：客户端发起第三个报文——ACK报文：
  
  客户端收到服务器报文后，向服务器回应ACK报文，把收到的 server_isn + 1 后填入确认应答号字段 ，并将TCP 首部 ACK 标志位置为 1 ，最后把ACK报文发送给服务端，这次报文可以携带客户端到服务器的数据，之后客户端处于 ESTABLISHED 状态。
  服务器收到应答报文后，也进入 ESTABLISHED 状态。
  【tips】当客户端和服务器都进入ESTABLISHED状态后，客户端和服务器之间就可以开始双向传递数据了。
  
  
  
  
• 至此，三次握手完成，连接建立。

        

• 四次握手：四次握手是指将三次握手时服务器返回的SYN+ACK报文分两次返回，先返回ACK报文，再返回SYN报文。因此四次握手可以优化成三次握手，有了三次握手就没必要四次握手了。
  
  

• ①三次握手才可以阻止重复历史连接(序列号过期或超时的连接叫历史连接)的初始化(主因)：
      假设客户端给服务器发送了一个SYN报文（seq=100），但是这个报文由于网络波动被阻塞了，没有到达服务器，此时客户端又发送了一个新的SYN报文（seq=200）【注意不是重传，重传的SYN的序列号是一样的】，让我们看一下三种握手都是怎么做的？
  
  • 三次握手：当旧的SYN报文(seq=100)先到达服务端，服务端会返回⼀个SYN+ACK报文，此时的ACK是100+1；客户端收到后，发现不是想要的200+1，就判断这是⼀个历史连接，客户端就会发送一个RST 报文给服务端，表示中止这⼀次连接。
    
    
    
    
  • 两次握手：两次握手情况下，当服务端收到旧的SYN报文(seq=100)后就建立了连接，但是服务端并不知道这是历史连接，并且在返回给客户端的报文中携带了数据(因为建立了连接所以会携带数据)，但是客户端通过收到的SYN+ACK报文，发现这是历史连接；对于客户端来说，它根本来不及在服务端给客户端发送数据前来阻止这个历史连接，导致这个历史连接被创建，服务端白白发送了数据。
    
    
    
    
    
    
  • 因此，要解决阻止重复历史连接建立的问题，客户端就必须在服务端发送数据之前来阻止建立历史连接，而这个功能的实现就需要三次握手。
  
  
  
• ②三次握手才可以同步双方的初始序列号：
  • 三次握手：当客户端给服务器发送携带了自己的初始序列号的SYN报文时，需要服务器返回一个ACK报文，表示收到了客户端的SYN报文，同样的在这个ACK报文中还要携带服务器自己的初始化序列号，也就是说服务器返回的是SYN+ACK报文；客户端收到这个SYN+ACK报文后，再发送一个ACK报文来确保服务端的SYN被成功接收；这样一来一回就能保证双方的初始化序列号被可靠同步。
  • 两次握手：两次握手只能保证客户端的初始序列号能被服务器成功接收，无法保证服务器的被客户端成功接收(因为服务器光发出去了，不管客户端收没收到都会建立连接)。
  • 四次握手：四次握手其实也能够可靠同步双方的初始化序列号，但由于第二步和第三步可以优化成一步，所以就成了三次握手。
    
    
    
    
  • 【tips】为什么要同步通信双方的序列号？
    
    ——序列号是实现可靠传输的一个关键因素，其作用如下：
              a. 接收方可以根据序列号进行重复数据的去重和按序接收数据；
              b. 通过ACK报文中的序列号可以识别发出去的数据包中，哪些已经被对方收到了。
    
    
• ③三次握手才可以避免资源浪费：
  • 两次握手：假设服务器收到大量来自客户端的SYN报文，因为是两次握手，服务器只要收到一个SYN报文就要建立连接，为这些连接分配资源。因此两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求 SYN 报文，造成重复分配资源。
    
    
    
    
• 总结：TCP 建立连接时，通过三次握手能阻止历史连接的建立，能减少双方不必要的资源开销，能保证双方同步初始化序列号。而两次握手无法防止历史连接的建立，还会造成资源的浪费，也无法可靠的同步双方序列号。三次握手理论上就是最少的可靠连接建立，所以不需要使用更多的通信次数来进行四次握手了。
  
  

• 客户端打算关闭连接，向服务器发送⼀个TCP首部FIN被置1的FIN报文；
• 服务端收到FIN报文后，先向客户端返回一个 ACK 应答报文；
• 服务端处理完数据后，再向客户端发送 FIN 报文；
• 客户端收到服务端的 FIN 报文后，返回一个 ACK 应答报文，之后进入 TIME_WAIT 状态；
• 服务器收到 ACK 应答报文后，进入 CLOSED 状态，服务端完成关闭连接；
• 客户端在经过 2MSL时间后，自动进入 CLOSED 状态，客户端也完成连接的关闭。
  【tips】主动关闭连接的一方才有 TIME_WAIT 状态。
  

• 服务端通常需要等待完成数据的和处理和发送，所以服务端的 ACK报文 和 FIN报文 一般都会分开发送，因此比三次握手多了一次。

• ①防止历史连接中因网络延迟的数据包或者丢失重传的数据包被新的连接（与历史连接的端口号相同）复用。
          有相同端口的 TCP 连接被复⽤后，被延迟的相同四元组(TCP四元组可以唯一确定一个连接)的数据包抵达了客户端，客户端有可能正常接收这个过期的报文，这就会产⽣数据错乱等严重的问题。
          假设服务端向客户端发送了 Seq=300 的报文和 Seq=301 的报文，因为是处于连接状态的，所以此次报文是夹带着数据的。但是由于网络原因导致 Seq=301 的报文阻塞在网络中；紧接着服务端以相同的四元组重新打开了新连接（即与历史连接的端口号相同的新连接），这时前面被阻塞的 Seq=301 抵达了客户端，而且它的序列号刚好在客户端的接收窗口内，因此客户端会正常接收这个数据报文，但是这个数据报文是上一个连接残留下来的，这样就产生了数据错乱等问题。
        就是为了防止历史连接中的数据被后面相同四元组的连接错误的接收，TCP 设计了 TIME_WAIT 状态。这个状态会持续 2MSL 时长，这个时间足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。
  
  
  
  
  
• ②保证被动关闭连接的一方，能够正确关闭。
        如果没有 TIME_WAIT 状态，客户端发送ACK报文后直接进入CLOSED状态关闭连接，假设第四次挥手的ACK报文丢了，服务器会一直等待这个ACK报文；当客户端想发起连接向服务器发送SYN报文时，服务器会返回RST报文，连接建立会关闭。
        有了 TIME_WAIT 状态，即使ACK报文丢失了，客户端在一段时间内仍然能够接收服务器重发的
  FIN 报文并对其进行响应，这样大概率能保证最后一个ACK被服务器收到，让服务器也正常关闭连接。
  
  
  

• MSL 指的是报文最大存活时间( Maximum Segment Lifetime)，超过这个时间报文将被丢弃。
• 2MSL：网络中可能存在发送方的数据包，当这些发送方的数据包被接收方处理后⼜会向发送方发送响应，所以一来一回需要等待 2 倍的时间。
          比如被动关闭方没有收到断开连接的最后一个 ACK 报文时，就会触发超时，重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方，这样一来一回刚好是 2 个 MSL。
  可以看到 2MSL时长其实是至少允许报文丢失一次。
  
  
• 2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有到达服务端，客户端⼜接收到了服务端重发的 FIN 报⽂，那么 2MSL 时间将重新计时。

• 内存资源占用；
• 对端口资源的占用，一个 TCP 连接至少要消耗⼀个本地端口，如果连接发起方的 TIME_WAIT 状态过多，占满了所有端口资源，会导致无法建立新连接。

<div> <span style="color:#2C3E50;"><span style="color:#000000;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="color:#2C3E50;">我们可以在调用 bind 前，<strong>对 socket 设置 <span style="color:#E53333;">SO_REUSEADDR</span> 属性</strong>。</span></span></span> </div> <div> <span style="color:#2C3E50;"><span style="color:#000000;"><span style="color:#2C3E50;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SO_REUSEADDR 的作用是：如果当前启动的进程绑定的 IP+PORT 与处于 TIME_WAIT 状态的连接占用的 IP+PORT 存在冲突，但是要启动的进程使用了 SO_REUSEADDR 属性，该进程就可以绑定成功。</span></span></span> </div> <div> <span style="color:#2C3E50;"><span style="color:#000000;"><span style="color:#2C3E50;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 可以。</span></span></span> </div> <div> <span style="color:#2C3E50;"><span style="color:#000000;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TCP 连接是由<strong>四元组</strong>（源IP地址，源端口，目的IP地址，目的端口）<strong>唯一确认</strong>的，<strong>只要四元组中的一个元素发生了变化，那么就表示不同的 TCP 连接</strong>，不会因为客户端的端口号相同，而导致连接冲突的问题。</span></span> </div> <div> <span style="color:#2C3E50;"><span style="color:#000000;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 这<strong>取决于客户端是否与同一服务器(即 ip 和端口号相同)建立连接</strong>。</span></span> </div> <div> <ul> <li> <span style="color:#2C3E50;"><span style="color:#000000;">如果客户端都是与同一个服务器建立连接，那么客户端 TIME_WAIT 状态的连接过多，当端口资源被耗尽，就无法与这个服务器再建立连接了。</span></span> </li> <li> <span style="color:#2C3E50;"><span style="color:#000000;">但是，因为<strong>只要客户端连接的服务器不同，端口是可以重复使用的(参考第(5)问)</strong>。所以这种情况下就可以建立新的连接了。</span></span> </li> </ul> </div> <div> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 在<strong>客户端</strong><span style="color:#000000;">开启&nbsp;</span><span style="color:#2C3E50;"><strong><span style="color:#000000;">net.ipv4.tcp_tw_reuse 内核参数(很好理解，tw_reuse就是time-wait reuse的意思)</span></strong><span style="color:#000000;">。</span></span> </div> <div> <span style="color:#2C3E50;"><span style="color:#000000;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;开启后，客户端<strong>调用 connect 函数选择端口</strong>时，如果已经被同一连接占用，就会<strong>判断该连接是否处于 TIME_WAIT 状态</strong>，如果处于 TIME_WAIT 状态<strong>且持续时间超过了 1 秒</strong>，就会<strong>重用(reuse)</strong>这个连接，然后就可以正常使用该端口与同一服务器建立连接了。</span></span> </div> 

• ①查找DNS缓存（浏览器缓存→本地缓存→路由器缓存→ISP缓存）
  • 先查找浏览器的DNS缓存，看是否有目标IP地址；
  • 如果浏览器缓存中没有，浏览器就会对操作系统发起系统调用，查询本地缓存；
  • 如果本地缓存中没有，浏览器就会查询与之相连的路由器缓存；
  • 如果路由器缓存中没有，浏览器会检查ISP缓存（本地通信服务商）。
  如果都没有查询到⽬标IP地址，就发起DNS查询。
• ②发起DNS请求(是否同一子网→DNS递归查询请求)
  • 首先判断DNS服务器和主机是否在同一子网：如果
    • 在同一子网，则采用 ARP (地址解析协议)对 DNS 服务器进行 ARP 查询
    • 不在同一子网，则对 默认网关 进行ARP查询
  • 如果还是查不到 IP 地址，则根据拿到的 DNS 服务器或者默认网关的 IP 地址进行 DNS 请求：
    • 使用53号端口先向本地 DNS 服务器发送 UDP 请求包(此处一般使用 UDP 协议，如果响应包太大，就使用 TCP 协议)。如果没有查到目标 IP 地址，它会发送⼀个递归查询请求，向高层DNS服务器查询，直到查到 IP 地址，然后将结果返回
  【tips】DNS 是分布式域名服务器，每台服务器只维护⼀部分 IP 地址到网络地址的映射。
  
  
• ③封装TCP数据包
  • 将应⽤层传下来的实际数据，在传输层添加TCP⾸部；
  • 将传输层传下来的数据在网络层添加IP⾸部；
  • 将⽹络层传下来的数据，在数据链路层添加以太网⾸部，并在传输介质中进⾏传输。
• ④浏览器与目标服务器建立TCP连接
  • 经过DNS域名解析后，浏览器会收到⽬标服务器的IP和MAC地址，然后经过三次握手后建⽴TCP连接；
  • 如果使用HTTP协议(端口号80)，浏览器发送请求到服务器，服务器直接返回结果；
  • 如果使用HTTPS协议(端口号443)，浏览器发送请求到服务器，服务器会返回⼀个以 3 开头的重定向消息，告诉浏览器使⽤的是 HTTPS，IP 没变，只是端⼝号变成 443；完成四次挥手；重新建⽴ TCP 连接，将端⼝号修改为 443，同时沟通好双⽅的使⽤的认证算法、加密和解密算法，在这个过程中也会检查对⽅的 CA 安全证书，采⽤ SSL 加密技术进⾏传输数据。
• ⑤浏览器发送HTTP/HTTPS请求到web服务器
  
  
• ⑥服务器处理请求并返回⼀个响应
  
  ⼀般响应包含：请求的页面以及状态码，压缩类型，如何缓存的页面，设置的cookie；
• ⑦最后通过浏览器渲染HTML骨架、检查HTML标记并发送GET请求获取页面其他元素，如图像、CSS样式、JS文件等，最后显示HTML页面
  【tips】静态资源⼀般由浏览器缓存，再次访问时，不用重新请求。
  
  
  

• 单点故障
  如果 DNS 服务器崩溃(单点故障)，会导致整个网络随之瘫痪。
  
• 通信容量
  一台 DNS 服务器要处理所有 DNS 查询，这种查询级别可能是上百万上千万级，⼀台服务器很难满足。
  
• 远距离集中式数据库
  单个 DNS 服务器不可能邻近所有的⽤户，查询请求肯定会经过低速和拥堵的链路，造成严重的时延。
  
• 维护成本巨大，需要频繁更新。

• 递归查询
  
  DNS 服务器接收到DNS客户端的请求，将请求的资源响应给客户端；如果无法找到请求资源记录，则返回错误消息。
  在递归查询模式下，用户主机和本地DNS服务器都是只发送一次请求：
      用户主机→本地DNS服务器→根域名DNS服务器→顶级域名DNS服务器→权威域名DNS服务器→得到映射结果
      用户主机←本地DNS服务器←根域名DNS服务器←顶级域名DNS服务器←权威域名DNS服务器←映射结果
  
  
  
  
  
• 迭代查询
  DNS 服务器收到DNS客户端请求后，不会直接返回查询结果，而是告诉客户端另一台DNS 服务器地址，客户端再向这台 DNS 服务器发送请求，依次循环直到返回查询结果或发生错误或超时为止。
  在迭代查询模式下，用户主机只发送一次请求，本地DNS服务发送不少于一次请求：
  
  本地DNS服务器→根域名DNS服务器，根域名DNS服务器→(顶级域名DNS服务器的IP地址)→本地DNS服务器；
  本地DNS服务器→顶级域名DNS服务器，顶级域名DNS服务器→(权威域名DNS服务器的IP地址)→本地DNS服务器；
      本地DNS服务器→权威域名DNS客户端，权威域名DNS服务器→(能够解析的查询结果)→本地DNS服务器；
  本地DNS服务器→(目标ip地址)→客户端
  
  
  
  
  
  
  
• 非递归查询
  当请求主机查询 DNS 服务器来获取DNS服务器有权访问的记录时通常会进⾏此查询，因为DNS服务器对该记录具有权威性，或者该记录存在于其缓存内。
  

• 客户端(Client)：服务调用发起方，也称为服务消费者。
• 客户端存根(Client Stub) ：该程序运行在客户端所在的计算机上，主要用来存储要调用的服务器的地址，负责将客户端请求远端服务器程序的数据信息打包成数据包，通过网络发送给服务端Stub程序；还要接收服务端Stub程序发送的调用结果数据包，并解析返回给客户端。
• 服务端(Server)：远端的计算机上运行的程序，其中有客户端要调用的方法。
• 服务端存根(Server Stub)：接收客户Stub程序通过网络发送的请求消息数据包，并调用服务端中真正的程序功能方法，完成功能调用；其次，将服务端执行调用的结果进行数据处理打包发送给客户端Stub程序。

• 客户端调用函数（函数3个参数：待调⽤的接口名+函数名，待调⽤函数的形参和接收结果的指针）  
• 客户端存根收到调⽤之后将 待调⽤的接⼝名和函数名、待调⽤函数的参数和执⾏函数后接收执⾏结果的指针类型 打包序列化成二进制数据，通过网络传输到服务端
• 服务端反序列化从客户端传来的数据，根据反序列化后的数据去找到并执行客户端需要调用的函数
• 将函数执行的结果序列化成二进制数据，通过网络传输给客户端
• 客户端反序列化收到的⼆进制数据，得到执行结果

• 传输层（TCP传输插件，HTTP传输插件）
• 协议层（协议插件，序列化插件，解压缩插件）
• 集群层（服务发现插件，连接管理插件，负载均衡插件，路由插件，容错插件，配置管理插件）
• 入口层（动态代理插件，链路追踪插件，过滤链插件）

• Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
• Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
• Partition tolerance （分区容错性）：
          Partition（分区）：因为 网络故障或其它原因导致分布式系统中的 部分节点与其它节点 失去连接(没有宕机)，形成独立分区。
          Tolerance（容错）：在集群 出现分区时，整个系统也要持续对外提供服务。

• AP 模式：保证了可用性和分区容错性。各子事务分别执行和提交，允许临时出现结果不一致，然后采用弥补措施恢复数据即可，实现数据的最终一致(弱一致)。
• CP 模式：保证了一致性和分区容错性。各子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态(基本可用)。

• 服务平台管理端创建⼀个服务根目录
• 当服务提供方发起注册时，会在提供方目录中创建一个临时节点，存储自己的注册信息
• 当服务调用方(服务请求方)发起订阅时，会在调用方目录中创建一个临时节点，存储自己的信息，同时会监控提供方目录中所有的服务节点数据
• 当提供方目录下有节点数据发生变更时，ZooKeeper 就会通知给发起订阅的服务调用方

• 注册中心节点收到注册请求的时候，服务列表发⽣变化，会发送⼀个消息到消息总线中，每个消息都有⼀个递增的版本号  
• 消息总线会主动推送消息到各个注册中⼼中，注册中⼼也会定时拉取消息，获取到的消息放到消息回放中，相当于⼀个接⼝，⽤来存可以调⽤的⽅法，只存⼤于本地版本号的消息，从⽽实现⼀致性  
• 消费者订阅从注册中⼼内存获取到所有接⼝信息，然后存到消费者缓存⾥  
• 采⽤推拉模式，消费者可以及时的拿到服务端中变化的情况和内存缓存的数据合并