计网知识总结

计算机网络知识总结

OSI七层模型

• 应用层：计算机用户，以及各种应用程序和网络之间的接口，功能是**直接向用户提供服务，完成用户希望在网络上完成的各种工作。**该层的协议有：FTP（文件传输协议）、DNS（域名解析协议）、SMTP（简单邮件传输协议）、TELNET（TCP/IP终端仿真协议）、HTTP（超文本传输协议）、HTTPS。

• 表示层：**对来自应用层的命令和数据进行解释，对各种语法赋予相应的含义，并按照一定的格式传送给会话层。主要处理了用户信息的表示问题，例如编码、数据格式转换和加密解密等。**该层的协议有：LPP（轻量级表示协议）、XDP（外部数据表示协议）

  • 数据格式处理：协商和建立数据交换的格式，解决各应用程序之间在数据格式表示上的差异。
  • 数据的编码：处理字符集和数字的转换。
  • 压缩和解压缩：减少数据的传输量。
  • 数据的加密和解密：提高网络的安全性。

• 会话层：该层是用户应用程序和网络之间的接口。组织和协调两个会话进程之间的通信，并对数据交换进行管理。用户可以按照半双工、单工和全双工的方式建立会话。当建立会话的时候，用户必须提供他们想要连接的远程地址，例如xxx.com。该层的协议有：SSL（安全套接字层协议）、TLS（传输层安全协议）、RPC（远程过程调用协议）。

  • 单工：单工就是A只能发信号，B只能接受信号，通信是单向的。
  • 半双工：一个时间段内只有一个动作发生，要么发送，要么接受。
  • 全双工：指交换机在发送数据的同时也能够接受数据，两者同步进行。

• 传输层：**它提供了端到端的数据传输服务，并可在互联网络上的发送主机和目标主机之间建立逻辑连接，将来自上层应用的数据进行分段和重组，并将它们合并到一个数据流中。**其中TCP和UDP就在这一层。

• 网络层：利用数据链路层所提供的相邻节点间的无差错数据传输功能，通过路由选择和中继功能，实现两个网络设备之间的连接。该层的协议有：IP（IPV4、IPV6）、ICMP、IGMP。

• 数据链路层：一个可靠的点对点的数据直链。在物理层提供的比特流的基础上，通过差错控制、流控等方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。该层的协议有：PPP（点对点协议）、FR（帧中继）、HDLC（通用数据链路控制协议）、ARP（地址解析协议）、RARP。

  • MAC（介质访问控制）子层：解决共享性网络中多用户对信道竞争的问题，完成网络介质的访问控制。
  • LLC（逻辑链路控制）子层：建立和维护网络连接，执行差错校验、流量控制和链路控制。

• 物理层：一个不一定可靠的点对点数据直链。利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。该层的协议有IEEE802.3。

模型的优点：

• 解决了异种网络互连时所遇到的兼容性问题，其将服务、接口和协议这三个概念明确区分：服务说明某一层为上一层提供一些什么功能，接口说明上一层如何使用下层的服务，协议涉及如何实现本层服务。
• 这使得各层之间具有很强的独立性，互连网络中各个实体采用什么样的协议是没有限制的，只需要向上提供相同的服务并且不改变相邻层的接口就可以了。并且使网络的不同功能模块担当不同的职责，减少了问题的复杂程度，一旦网络发生故障，可以迅速的定位层次，便于查找和纠错。

TCP/IP四层协议

• 应用层（会话层、表示层、应用层）：TCP/IP模型将OSI参考模型中的会话层和表示层的功能合并到应用层实现。其向用户提供一组常用的应用程序，例如电子邮件、文件传输访问、远程登录等。应用层面向不同的网络应用引入了不同的应用层协议。

  • 远程登录TELNET使用TELNET协议提供在网络其它主机上注册的接口。
  • TELNET会话提供了基于字符的虚拟终端。
  • 文件传输访问FTP使用FTP协议来提供网络内机器间的文件拷贝功能。

• 传输层：**提供应用程序之间的通信，使得源端主机和目标端主机上的对等实体可以进行会话。**其功能包括：

  • 格式化信息流
  • 提供可靠传输：传输层协议规定接收端必须发回确认，并且假如分组丢失，必须重新发送。

  该层定义了两种服务质量不同的协议：传输控制协议TCP（Transmission Control Protocol）和用户数据报协议UDP（User Datagram Protocol）

  • TCP协议是一个面向连接的、可靠的协议，它将一台主机发出的字节流无差错的发往互联网上的其他主机。**在发送端，它负责把上层传送下来的字节流分成报文段并传递给下层；在接收端，它负责把收到的报文进行重组后递交给上层。**TCP协议还要处理端到端的流量控制，以避免缓慢接收的接收方没有足够的缓冲区接收发送方发送的大量数据。
  • UDP协议是一个无连接的、不可靠的协议，主要适用于不需要对报文进行排序和流量控制的场合。

• 网络层：整个TCP/IP的核心，功能是把分组发往目标网络或主机。为了尽快的发送分组，可能需要沿不同的路径同时进行分组传递。因此分组到达顺序可能不同，则这就需要上层必须对分组进行排序。该层还定义了分组格式和协议，即IP协议。

  • 处理来自传输层的分组发送请求：收到请求后，将分组装入IP数据报，填充报头，选择去往信宿机的路径，然后将数据报发往适当的网络接口。
  • 处理输入数据报：首先检查其合法性，然后进行寻径：
    • 该数据报已到达信宿机，则去掉报头。
    • 该数据包尚未到达信宿，则转发该数据报。
  • 处理路径、流控、拥塞等问题。

• 网络接口层（物理层、数据链路层）：负责接收IP数据并通过网络发送，或者从网络上接收物理帧，抽出IP数据报交给网络层。实际上TCP/IP并没有真正描述这一层的实现，只是要求能够提供给它上层一个访问接口，以便在其上传递IP分组。

HTTP定义、性能和特性

• HTTP：超文本传输协议，即HyperText Transfer Protocol。是一个基于请求响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议，所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

• HTTP的特点

  • 简单：基本报文格式是header+body，头部信息也是key-value的简单文本格式，易于理解。
  • 灵活和易于扩展：HTTP协议里面各类请求方法，URI/URL、状态码、头字段等都没有固定死，允许开发人员自定义和扩充。由于HTTP是工作在应用层的，其下层可以随意变化。
  • 应用广泛和跨平台。
  • 无连接：
    • 每一个访问都是无连接，服务器挨个处理访问队列里的访问，处理完一个后就关闭连接，然后处理下一个新的。
    • 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并受到客户的应答后断开连接。
  • 无状态：
    • 好处：是服务器不会去记忆HTTP的状态，所以不需要额外的资源去记录状态信息，可以减轻服务器的负担，能够把更多的CPU和内存用来对外提供服务。
    • 坏处：由于服务器没有记忆能力，当在进行一些有关联性的操作的时候就必须一直验证信息。例如：登录-》添加购物车-》下单-》结算-》支付，这一系列的操作都需要知道用户的身份才行，但服务器是不知道这些操作有关联的。解决此问题的最典型案例就是cookie：通过请求和响应报文中写入cookie信息来控制客户端的状态，相当于服务器会下发一个装有客户信息的贴纸，后续客户端请求服务器的时候带上这个贴纸就可以了。
  • 明文传输：
    • 好处：传输过程中的信息方便预读，通过F12可以直接查看，对调试工作带来了极大的便利性。
    • 坏处：信息裸奔，毫无隐私可言，十分不安全。HTTP的安全问题可以通过引入SSL/TLS层的HTTPS的方式解决。

• HTTP1.1的三个特性：

  • 长连接：HTTP1.0每发起一个请求，都要新建一次TCP连接（三次握手），而且是串行请求，这增加了通信开销。为了解决TCP的连接问题，HTTP1.1提出了长连接的通信方式：只要任意一端没有明确提出断开连接，则保持TCP的连接状态。
  • 管道网络传输：同一个TCP连接里面，客户端可以发送多次请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。虽然如此，但服务器还是按照顺序，先回应最先发出的请求，要是一开始的请求回应的特别慢，后面就会有许多请求排队等着，造成队头堵塞。
  • 队头阻塞：当顺序发送的一个请求因为某种原因被阻塞时，后面排队的所有请求也一同被阻塞了，导致客户端一直请求不到数据。

HTTP对比HTTPS

区别

• HTTP是超文本传输协议，其中的信息是明文传输的，其连接简单，是无状态的；HTTPS是HTTP协议再加上SSL（安全套接字层），可以进行加密传输，身份认证，比HTTP协议安全。
• HTTP不验证通信方的身份，通信方的身份有可能遭遇伪装，且无法证明报文的完整性，报文可能受到篡改；HTTPS需要到CA申请证书来确保身份。
• HTTP和HTTPS的使用的是完全不同的连接方式，端口也不一样，前者是80，后者是443。
• HTTPS连接服务器资源占用高很多，连接缓存不如HTTP高效，流量成本高。
• HTTPS协议的握手阶段比较费时，对网站的响应速度有影响，所以一般采用分而治之，12306就是主页使用HTTP，有关用户信息的采用HTTPS。

解决的问题

HTTP是明文传输，所以存在以下三个问题：

• 窃听风险：通信链路上可以获取通信内容。
• 篡改风险：强制植入垃圾广告等。
• 冒充风险：容易冒充其他网站。

HTTPS在HTTP与TCP层之间加入了SSL/TLS协议，可以很好的解决上述问题：

• 信息加密：交互信息无法被窃取。
• 校验机制：无法篡改通信的内容，篡改了就不能正常显示。
• 身份证书：证明某网站是真正的。

HTTP vs TCP

• HTTP是应用层协议，主要解决如何包装数据；而TCP协议是传输层协议，主要解决数据如何在网络中传输。
  • 为什么有TCP还需HTTP：我们在传输数据的时候，只可以使用（传输层）TCP协议，但是没有应用层用户就无法识别数据的内容，如果想要使传输的数据有意义，则必须使用应用层协议。
• HTTP是建立在TCP协议之上的。

HTTPS加密的具体方式

HTTPS不是新协议，而是让HTTP先和SSL（Secure Sockets Layer）通信，再由SSL和TCP通信。也就是说HTTPS使用隧道进行通信**，通过使用SSL，HTTP具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。**

• 认证：使用第三方数字证书认证机构来对通信方进行认证。将服务器公钥放入到数字证书中，解决了冒充的风险。只要证书是可信的，公钥就是可信的。

  • 为什么需要CA认证机构颁发证书？

    • HTTP协议被认为不安全是因为传输过程中容易被监听者勾线监听、伪造服务器，而HTTPS协议主要解决网络传输中的安全性问题。假设不存在认证机构，任何人都可以制作证书，这样就会带来中间人攻击问题：客户端虽然发起的是HTTPS请求，但是客户端完全不知道自己的网络已经被拦截，传输内容被中间人全部窃取。

      

• 加密：对称加密和非对称加密混合加密（传输数据用对称加密的方式，交换会话密钥采用非对称加密）在通信建立前采用非对称加密的方式交换会话秘钥，后续不再使用非对称加密。在通信过程中全部使用对称加密的会话秘钥的方式加密明文数据。

  • 何为对称加密和非对称加密？

    • 对称加密也叫私钥加密，指加密和解密使用相同的秘钥的加密算法。
    • 非对称加密则需要两个密钥：公开密钥和私有密钥，且这两个是成对出现的。其中公开密钥是对外公开的，所有人都可以获取到；而私有密钥是不公开的。

  • 为什么采用混合加密？

    • 对称加密只使用一个秘钥，运算速度快，秘钥必须保密，无法做到安全的密钥交换。
    • 非对称加密使用两个秘钥：公钥和私钥，公钥可以任意分发而私钥保密，这样解决了密钥交换的安全性问题。

  • 为什么数据传输是对称加密？

    • 非对称加密的解密效率非常低，而HTTP的应用场景中通常端对端之间存在大量的交互，非对称加密的效率是无法接受的。
    • 在HTTPS的中只有服务端保存了私钥，一对公私钥只能实现单向的加密解密，所以HTTPS中内容传输加密是对称加密。

  • 加密的整体过程？

    • **认证服务器：**浏览器内置一个受信任的CA机构列表，并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证办法的服务器证书，**如果认证该服务器证书的CA机构存在于浏览器受信任的CA机构列表中，并且服务器证书中的信息与当前正在访问的网站（域名等）一致，那么浏览器就认为服务端是可信的，并从服务器证书中取得服务器公钥，用于后续流程。**否则浏览器将提示用户，根据用户的选择来决定是否继续。当然我们可以管理这个受信任的CA机构列表来添加我们要信任的CA机构，或者移除。
    • 协商会话秘钥：也商量出对称加密私钥的过程。客户端在认证完服务器获得服务器的公钥之后，利用该公钥与服务器进行加密通信，协商出两个会话秘钥，分别是用于加密客户端往服务器发送数据的客户端会话秘钥，和用于加密服务器往客户端发送数据的服务器会话秘钥。在已有服务器公钥可以加密通讯的前提下，还要协商两个对称秘钥的原因是非对称加密相对复杂度更高，在数据传输的过程中使用对称加密可以节省计算资源。此外会话秘钥是随机生成，每次协商都会有不一样的结果，所以安全性也比较高。
    • **加密通讯：**此时客户端和服务器双方都有了本次通讯的会话秘钥，之后传输的所有HTTP数据都会通过会话秘钥加密。这样网络上的其他用户将会很难窃取和篡改客户端和服务器之间传输的数据，从而保证了数据的私密性和完整性。

• 完整性保护：SSL提供报文摘要功能来进行完整性保护。HTTP也提供了MD5报文摘要功能，但不安全。该功能能够为数据生成独一无二的“指纹”以用于校验数据的完整性，解决了篡改的风险。客户端在发送明文之前会通过摘要算法算出明文的“指纹”，发送的时候把“指纹 + 明文”一同加密成密文后，发送给服务器。服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的“指纹”和当前算出的“指纹”作对比，如果相同说明数据是完善的。

SSL流程

SSL流程是HTTPS的安全信道建立的具体步骤：

• 客户端通过发送Client Hello报文开始进行SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表（所使用的加密算法以及密钥长度等）
• 服务器得知可进行SSL通信时，会以Server Hello报文作为应答，和客户端一样，在报文中包含SSL版本以及加密组件，服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。之后发送Certificate报文（公开秘钥和证书），最后服务器发送Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。
• 客户端以Client Key Exchange报文作为回应（包含通信加密中使用一种Pre-masterSecret随机密码串），该报文用之前的公开密钥进行加密。接着客户端继续发送Change Ciper Spec报文，该报文提示服务器在此报文之后通信会采用Pre-masterSecret密钥加密。最后客户端发送Finish报文，该报文包含连接至今全部报文的整体校验值，这次握手是否成功取决于服务器是否能够正确解密该报文。
• 服务器同样发送Change Cipher Spec报文和Finished报文。

总的来说就是：

• 交换SSL协议版本号
• 选择一个通信双方都支持的加密方式
• 对两端实现身份认证
• 密钥交换

HTTP响应状态码

• 1xx（继续）：HTTP1.1新引入。请求者应当继续提出请求，服务器返回此代码表示已经收到请求的第一部分，正在等待其余部分。
• 2xx（成功）：表示成功处理了请求的状态码。
• 3xx（重定向）：要完成请求需要进一步操作。这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。
• 4xx（请求错误）：客户端请求发生了错误，妨碍了服务器的处理。
• 5xx（服务器错误）：服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。

转发和重定向

• 重定向地址栏发生变化；转发地址栏路径不变
• 重定向可以访问其他站点的资源；转发只能访问当前服务器下的资源
• 重定向是两次请求，不能使用request对象来共享数据；转发是一次请求，可以使用request对象共享数据

HTTP报文

HTTP请求报文由请求行、请求头部、空行和请求体4部分组成。

• 请求行由请求方法字段、URL字段和HTTP协议版本字段三部分组成，他们之间用空格隔开。常用的HTTP请求方法有：GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。其中前三者是HTTP1.0就有的，后五个是HTTP1.1出现
  • GET：**当客户端要从服务器中读取某个资源时使用该方法。**GET方法要求服务器将URL定位的资源放在响应报文的数据部分回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个英文问号代表URL的结尾与请求参数的开始。例如/page?size=11&total=111
  • POST：**当客户端给服务器提供信息时使用该方法。**POST方法一般做一些表单数据的提交，将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据。
  • HEAD：**类似GET，只不过服务端接受到HEAD请求后只返回响应头，而不会发送响应内容。**当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容。
    • 在不获取资源的情况下了解资源的情况（判断类型）
    • 通过查看响应中的状态码看看对象是否存在
    • 通过查看首部，测试资源是否被修改
  • PUT：**类似POST，但如果两个请求相同，后一个请求会把第一个请求覆盖掉。**一般用于修改资源。
  • DELETE：请求服务器删除请求URL所指定的资源，但不一定都会执行，因为服务器可以在不通知客户端的情况下撤销这个请求。
  • OPTIONS：**用于获取当前URL所支持的方法。**若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。
  • TRACE：允许客户端在最终将请求发送服务器时，查看它变成了什么样子。
  • CONNECT：把服务器作为跳板，让服务器代替用户去访问其它网页，之后把数据返回给用户。
• 请求头部：由关键字和值组成，每行一对，关键字和值用英文冒号分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：
  • User-Agent： 产生请求的浏览器类型
  • Accept： 客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组， 用“ / ” 指示可接受全部类型， 用“ type/* ”指示可接受 type 类型的所有子类型
  • Accept-Language： 客户端可接受的自然语言
  • Accept-Encoding： 客户端可接受的编码压缩格式
  • Accept-Charset： 可接受的应答的字符集
  • Host： 请求的主机名， 允许多个域名同处一个 IP 地址， 即虚拟主机
  • Connection： 连接方式(close 或 keepalive)
  • Cookie： 存储于客户端扩展字段， 向同一域名的服务端发送属于该域的 cookie;
  • Content-Length：实体的主体部分包含了多长的字节的数据
  • Content-Type：实体的主体部分文件类型
  • Date：服务器产生响应的时间
• 请求空行：最后一个响应头之后是一个空行，发送回车符和换行符，通知服务器以下不再有响应头部。
• 请求体：包含一个由任意数据组成的数据块。并不是所有的报文都有主体部分。是HTTP主要传输的内容。

GET和POST的区别

• 定义：GET方法的含义是请求从服务器获取资源，该资源可以是静态文本、页面、图片视频等。例如打开一个链接，浏览器就会发送一个GET请求给服务器，服务器就会返回链接中所有文字及资源；而POST方法则是反向操作，向URI指定的资源提交数据，数据就放在body里面。例如在某链接中填好注册信息点击提交，浏览器就会执行一次POST请求，把提交的信息放进了报文的请求体里，然后拼接好POST请求头，通过TCP协议发送给服务器。
• GET请求的参数会被完整的保留在浏览器历史记录里，而POST中的参数则不会；GET请求是通过URL进行参数传递，而POST则是放在Request Body中；GET请求在URL中传递的参数是有长度限制的，POST没有。
• GET请求会被浏览器主动缓存，而POST则不会。
• GET产生一个TCP数据包：浏览器把HTTP header和data一并发送出去，服务器响应200 ok；而POST产生两个数据包：浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok。ps：并不是所有的浏览器都会POST发送两个数据包。

HTTP1.0 vs HTTP1.1 vs HTTP2 vs HTTP3

• HTTP1.1支持长连接、请求的流水线处理。
  • HTTP1.0规定浏览器与服务器只保持短连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。
  • HTTP1.1则支持长连接，并且默认使用长连接。在同一个TCP连接中可以传送多个HTTP请求和响应，多个请求和响应可以重叠，同时进行。且增加了更多的请求头和响应头（host），方法等（PUT、DELETE、CONNECT、TRACE、OPTIONS）。不过该持久连接需要增加新的请求头来帮助实现，例如Connection的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。
  • HTTP1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。
• HTTP1.1还提供了与身份认证、状态管理和Cache缓存的机制有关的请求头和响应头，例如cache-control。HTTP1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。
• HTTP1.1新增加host字段
  • HTTP1.0认为每台服务器都绑定一个唯一的IP地址，因此请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，且他们共享同一个IP地址。
  • HTTP1.1的请求消息和响应消息都应支持host头域去标识主机，且请求消息中如果没有host头域会报出400Bad Request。
• HTTP1.1的带宽优化
  • HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如客户端只需要显示一个文档的部分内容，又或者下载大文件时需要支持断点续传，而不是发生中断后不得不重新下载完整的文件。
  • HTTP1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。在响应消息中的Content-Range头域声明返回的这部分对象的偏移值和长度。如果服务器响应的返回了对象所请求的范围内容，则响应码为206，它可以防止Cache将响应误以为是一个完整的对象。
  • 如果请求消息中包含比较大的实体内容，但不确定服务器是否能够接受该请求（例如是否有权限），此时如果贸然发出带大实体的请求，被拒绝也会浪费带宽。HTTP1.1加入了一个新的状态码100，**客户端事先发送一个只带头域的请求，如果服务器因为权限等原因拒绝了该请求，就返回响应码401；如果服务器接受此请求就会送响应码100，客户端就可以继续发送带实体的完整请求了。**ps：HTTP1.0不支持100响应码，但是可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。
• HTTP1.1还多定义了24个响应码，新加入了1xx表示服务器已经接受了一部分数据，请求者应该继续发送请求；还有409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
• HTTP1.1性能瓶颈
  • 头部未压缩：请求响应头部未经压缩就直接发送，首部信息越多延迟越大。如果发送多个请求，且他们的头部都很大，则会造成很大的系统开销。
  • 队头阻塞：服务器是按照请求的顺序响应的，如果服务器响应的很慢，或者有一个请求阻塞了，会导致客户端一直得不到数据，造成队头阻塞。
  • 受限的优先级设置：如果浏览器针对指定域名开启多个请求，若web页面某些资源比另外一些资源重要，这会加重资源的排队效应：即先请求优先级高的资源，在获取之后再请求优先级较低的资源，并且在请求优先级高的资源的时间区间内浏览器并不会发起优先级较低的新请求。
• HTTP2是基于HTTPS的，所以HTTP2的安全性是有保证的
  • 头部压缩：HTTP2会压缩header，如果同时发送多个请求，他们的头部都是一样或者相似，那么HTTP2会压缩重复的部分。即所谓的HPACK算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样的字段了，只发送索引号，这样就能提高速度了。
  • 二进制格式：HTTP2不像HTTP1.1里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。这样对计算机非常的友好，接受到报文时无需将明文转成二进制，而是直接解析二进制报文，增加了数据传输的效率。
  • 数据流：HTTP2数据包不是按顺序发送的。同一个连接里面连续的数据包，可能属于不同的响应。因此必须要对数据包做标记来指明其属于哪个响应。每个请求或者响应的数据报称为一个数据流，每个数据流都标记这一个独一无二的编号，其中规定：客户端发出的数据流编号为奇数，服务器发送的数据流编号为偶数。客户端还可以指定数据流的优先级，优先级高的请求，服务器就先响应该请求。
  • 多路复用来解决队头阻塞：HTTP2可以在一个连接中并发多个请求或者响应，而不是按照顺序一一对应。移除了HTTP1.1中的串行响应，不需要排队等待，也就不会再出现队头阻塞的问题，降低了延迟，大幅度的提高了连接的利用率。例如在一个TCP连接里，服务器收到了客户端A和B的两个请求，如果发现A处理过程非常耗时，于是就回应A请求已经处理好的部分，接着回应B请求，完成后再回应A请求剩下的部分。
  • 服务器推送：HTTP2还在一定程度上改善了传统的请求应答工作模式，服务器不再是被动的响应，也可以主动的向客户端发送消息。例如在浏览器刚请求HTML的时候，就提前把可能会用到的JS、CSS文件等静态资源主动发送给客户端，减少延时。
• HTTP2的问题在于多个HTTP请求在复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的，所以一旦发生丢包现象，就会触发TCP的重传机制，这样在一个TCP连接中的所有HTTP请求都必须等待这个丢了的包被重传回来，造成阻塞。并且HTTP2是基于HTTPS，不仅有TCP的握手，并且还有一个TCP + TLS的握手，需要两个握手时延的过程。
• HTTP3将HTTP下层的TCP协议换成了UDP来解决丢包问题。UDP是不管请求响应的顺序和丢包，即使发生丢包，其他的请求也不会阻塞。UDP是不可靠传输的，但是基于UDP的QUIC协议可以实现类似TCP的可靠传输。
  • QUIC是谷歌制定的一种基于UDP的低时延的互联网传输层协议，有自己的一套的传输机制保证传输的可靠性。当某个流发生丢包，只阻塞这个流，其他流不受影响。
  • TLS3升级省略最新的1.3版本，头部压缩算法也升级成了QPack
  • HTTPS要建立一个连接要花费六次交互（三次握手以及TLS/1.3的三次握手）；QUIC直接把以往的TCP和TLS/1.3的6次交互合并成了三次，减少了交互次数。

HTTP的长连接和短连接

• HTTP1.0默认使用短连接（无连接），即浏览器和服务器每进行一次请求响应，就建立一次TCP连接，请求响应完就中断连接。如果客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源， 如 JavaScript 文件、 图像文件、 CSS 文件等；当浏览器每遇到这样一个 Web 资源， 就会建立一个 HTTP 会话。这样很显然有个问题就是多次的建立中断TCP连接很浪费时间。
• HTTP1.1开始使用长连接，用以保持连接特性，使用长连接应该在头部加入Connection:keep-alive
• 优缺点：
  • 长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间，对于频繁请求资源的客户来说，较适合使用长连接。但问题是如果长连接一直不关闭的话，随着客户端的连接越来越多，服务器早晚会扛不住，这样服务端需要采取一些策略，例如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致服务端服务受损，或者可以设置每个客户端的最大长连接数。
  • 短连接对于服务器来说管理简单，存在的连接都是有用的连接，不需要额外的控制手段，但是如果客户端请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。
• 使用时机：
  • 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多。
  • 短连接适用于并发量大但是操作不频繁的情况下。

DNS相关知识

DNS使用的是TCP协议还是UDP协议

DNS：域名系统，是互联网的一项服务，它是一个将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。DNS使用TCP和UDP端口53。它的主要作用就是将域名翻译成IP地址，这过程叫做DNS域名解析。

• DNS在进行区域传输的时候使用TCP协议，域名解析时则使用UDP协议

• 区域传输：DNS规范规定了两种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息。

• 区域传输使用TCP主要有以下两点考虑：

  • 辅助DNS服务器会定时（一般三小时）向主域名服务器进行查询以便了解数据是否有变动。如果有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多的多（TCP一次能发1440字节）。
  • TCP是一种可靠的连接，保证了数据的准确性。

• 域名解析时使用UDP协议：客户端向DNS服务器查询域名，一般返回的内容都不超过512个字节，用UDP传输即可。不用经过TCP的三次握手，这样DNS服务器负载会更低，响应更快。

DNS劫持

域名劫持通过攻击域名解析服务器（DNS），或伪造域名解析服务器（DNS）的方法，把目标网站域名解析到错误的IP地址从而实现用户无法访问目标网站的目的或者蓄意或恶意要求用户访问指定IP地址（网站）的目的。其效果就是对特定的网址不能访问或访问的是假网址。

域名劫持一方面可能影响用户的上网体验，用户被引到假冒的网站进而无法正常浏览网页，而用户量较大的网站域名被劫持后恶劣影响会不断扩大；另一方面用户可能被诱骗到冒牌网站进行登录等操作导致泄露隐私数据。

解决办法：如果知道了通信的ip地址，可以通过ip地址直接访问。

DNS投毒

由于DNS采用UDP协议来传输查询和应答的数据包，属于简单的信任机制。对接收到的应答数据包仅进行原查询包IP地址、端口和随机查询ID的确认，而不会对数据包的合法性做任何分析。如果匹配，则接收其作为正确应答数据包，并进行DNS解析，并丢弃后续到达的所有应答数据包，这使得攻击者可以仿冒根DNS服务器向本地DNS服务器发送伪造的应答包，抢先完成污染本地DNS缓存。

DNS投毒破解，如果本地DNS缓存里面有数据的话，那么就无法成功了。

域名的分析

例如一个域名：www.hty.com

• 顶级域名（TLD）：.com
• 次级（二级）域名（SLD）：.hty，这一级域名是用户可以注册的
• 主机名（host）：www，又称为三级域名，这是用户在自己的域里面为服务器分配的名称，是用户可以任意分配的。

DNS域名解析

• 浏览器查看自身缓存看是否有和该域名对应的规则，有就直接返回，否则查看hosts文件看看其中有没有和该域名对应的规则，有的话直接使用hosts文件里面的ip地址。

• 如果hosts文件里面没有，浏览器会发出一个DNS请求到本地DNS服务器。本地DNS服务器一般由本地网络接入服务器商提供。该DNS请求到达本地DNS服务器后，本地DNS服务器会首先查询它的缓存记录，如果有的话可以直接返回结果，查不到的话还要向DNS根服务器进行查询。

• DNS根域名服务器如果有就返回，没有的话就告诉本地DNS服务器，可以到顶级域服务器上去继续查询，并给出顶级域服务器的地址。

• 本地DNS服务器继续向顶级域服务器发出请求，即.com域服务器，.com域服务器收到请求之后也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器解析出来的服务器地址。

• 最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在hosts文件缓存中，以便下次别的用户查询时，可以直接返回结果。

DNS迭代查询递归查询

主机向本地域名服务器的查询一般是采用递归查询：如果主机所询问的本地域名服务器不知道被查询的域名IP地址，那么本地域名服务器就是以DNS客户的身份，向其他根域名服务器继续发出查询请求报文（替主机继续查询），而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。

**本地域服务器向根域名服务器的查询的迭代查询：**当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器应该去哪一个域名服务器进行查询。然后让本地服务器进行后续的查询，根域名服务器通常是把自己知道的顶级域名服务器IP地址告诉本地域名服务器，让本地域名服务器向再向顶级域名服务器查询。顶级域名服务器要么给出IP地址，要么告诉本地服务器下一步应该向哪一个权限域名服务器（hty.com）进行查询。

浏览器输入URL之后发生了什么

1. 浏览器从URL中解析出服务器的主机名并将其转换为IP地址（DNS域名解析）

2. 浏览器建立一条与服务器的TCP连接（三次握手）

   • 在拿到域名对应的IP地址后，会以随机端口（1024-65535）向WEB服务器程序80端口发起TCP连接请求，该连接请求进入到内核TCP/IP协议栈（用于识别该请求），还有可能要经过Netfilter防火墙的过滤，最终到达WEB程序，最终建立TCP/IP连接。

3. 浏览器向服务器发送一条HTTP请求报文

4. 服务器对请求进行解析，并向浏览器回送一条HTTP响应报文

   • 服务器端收到请求后，由web服务器（准确说应该是http服务器）处理请求，诸如Apache、Ngnix（负载均衡）、IIS等。web服务器解析用户请求，知道了需要调度哪些资源文件，再通过相应的这些资源文件处理用户请求和参数，并调用数据库信息，最后将结果通过web服务器返回给浏览器客户端。

5. 浏览器对响应内容进行解析

6. 关闭TCP连接（四次挥手）

7. 渲染页面（构建DOM树、CSS规则树）

TCP三次握手和四次挥手

TCP报文格式：

• 序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。目的是解决乱序问题。
• 确认号：ack序号，占32位，只有ack标志位为1，确认序号字段才有效，确认方ack = 发送方seq + 1。
• 标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等
  • URG：紧急指针（urgent pointer）有效。
  • ACK：确认序号有效。
  • PSH：接收方应该尽快将这个报文交给应用层。
  • RST：重置连接。
  • SYN：发起一个新连接。
  • FIN：释放一个连接。
• 窗口大小：流量控制，用于标识自己的处理能力

三次握手：建立TCP连接

TCP连接必须是一方主动打开，另一方被动打开。握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始三次握手：

• 一：首先客户端向服务器端发送一段TCP报文。

  • 标记位为SYN = 1，ACK = 0，表示请求建立新连接；
  • 序列号为seq = x；+
  • 随后客户端进入SYN-SENT阶段。

• 二：服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段，并返回一段TCP报文。

  • 标志位为SYN = 1和ACK = 1，表示确认客户端的报文seq序列号有效，服务器能正常接收客户端发送的数据，并同意创建新的连接（即告诉客户端服务器接收到了你的数据）；
  • 序列号为seq = y，表示服务端作为发送者时，发送字节流的初始序号；
  • 确认号为ack = x + 1，表示收到客户端seq并将其值加1作为自己确认号ack的值，随后服务器端进入SYN-RCVD阶段。

• 三：客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。

  • 标志位ACK = 1，表示确认收到服务器端同意连接的信号（即告诉服务器我知道你收到我发的数据了）；
  • 序列号为seq = x + 1，表示收到服务器端确认号ack，并将其值作为自己的序号值；
  • 确认号为ack = y + 1，表示收到服务器端序列号seq，并将其值加1作为自己的确认号Ack的值；

  随后客户端进入EXTABLISHED（已建立）阶段。服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

在客户端与服务端传输的TCP报文中，双方的确认号ack和序号seq的值，都是在彼此seq和ack值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续握手，以此确保三次握手的顺利完成。

四次挥手：关闭TCP连接

TCP连接是双向的，连接的释放必须是一方主动释放，另一方被动释放。挥手之前主动释放连接的客户端结束ESTABLISHED阶段，开始四次挥手。

• 一：客户端想要释放连接，向服务端发送一段TCP报文

  • 标记位为FIN = 1，表示请求释放连接。
  • 序列号为seq = u
  • 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据（正常的确认报文依然能发送），但是客户端仍然能接受从服务器端传来的数据。

• 二：服务器端接受到从客户端发出的TCP报文后，得知客户端想要释放连接，随后服务端结束ESTABLISHED阶段，进入CLOST-WAIT阶段（关闭等待状态）并返回一段TCP报文

  • 标志位为ACK = 1，表示接收到客户端发送的释放连接的请求。
  • 序列号seq = v
  • 确认号为ack = u + 1，表示是在收到客户端报文的基础上，将其序列号seq值加1作为本段报文确认号ack的值。随后服务器端开始准备释放服务器端到客户端方向上的连接。
  • 客户端收到从服务器发出的TCP报文后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段。

前两次挥手既让服务器知道了客户端想要释放连接，也让客户端知道了服务端知道了自己想要释放连接的请求。于是可以确认关闭客户端到服务器端方向上的连接了。

• 三：服务器端自从发出ACK确认报文后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文。

  • 标记位为FIN，ACK，表示自己已经准备好释放连接了（此处的ACK并不是确认收到服务器端报文的确认报文）。
  • 序列号为seq = w
  • 确认号为ack = u + 1，表示是在收到客户端报文的基础上，将其序号seq值加1作为本段报文确认号ack的值。
  • 随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。
  • CLOST-WAIT阶段的存在就是确保服务端发送确认包让客户端得以知道；处理好还没有处理完的数据。

• 四：客户端收到从服务器发出的TCP报文，确认了服务器端已经做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文

  • 标记位为ACK，表示接收到服务器准备好释放连接的信号。
  • 序列号为seq = u + 1，表示是在收到了服务器端报文的基础上，将其确认号ack的值作为本段报文序列号的值。
  • 确认号为ack = w + 1，表示是在收到了服务器端报文的基础上，将其序列号seq的值 + 1作为本段报文确认号的值。

  随后客户端开始在TIME-WAIT阶段等待2MSL。服务器端收到了客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。客户端在TIME-WAIT阶段等待完2MSL后，进入CLOSED阶段，由此完成四次挥手。

  后两次挥手既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。

  在客户端与服务器端传输的TCP报文中，双方的确认号ack和序列号seq的值，都是在彼此seq和ack值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续挥手，以此确保了四次挥手的顺利完成。

为什么握手不是两次或者四次？

• 为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。如果只是两次握手，相当于第二次握手结束之后便建立连接，那么服务端无法确认客户端是否已经接收到自己的同步信号，如果该同意连接的信号因为一些原因丢失了，那么客户端和服务端的初始序列号始终无法一致，导致无法连接（客户端无法知道服务端是否接收到了自己想要连接的信号）。
• 本质上就是为了实现可靠数据传输，TCP通信的双方都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程就是通信双方互相告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤。如果只有两次握手，最多只有连接发起方的起始序列号可以得到确认，而另一方的序列号则得不到确认。
• 四次握手显然是没有必要的，因为三次已经可以保证了连接。第二次握手即表示了服务端收到了客户端的请求，又表示了服务端同意与客户端进行连接。

三次握手中如果丢包（报文丢失）了怎么办？

• 如果客户端发送给服务端的SYN中途被丢没有到达，则客户端会周期性的超时重传，直到收到服务端的确认。
  • TCP协议中，某端在进行一组请求应答时，在一定的时间范围内，只要没有收到应答的ACK包，不管是自己请求的对方没有收到，还是对方发来的自己没有收到，均认为发生丢包，触发超时重传机制。
  • 重传SYN会尝试三次，时间间隔分别是5.8s、24s、48s
• 如果服务端发送给客户端的SYN + ACK中途被丢没有到达：
  • 客户端认为自己发送的服务端没有收到，继续进行周期性的超时重传。
  • 服务端认为自己发送的没有送到，在规定时间没有收到ACK，触发超时重传。会在依次等待3s、6s、12s后重新发送SYN + ACK包。
• 如果客户端发送给服务端的ACK中途被丢没有到达服务端。此时客户端发送完ACK后认为连接已经建立，就进入了EXTABLISHED，可服务端因为没有收到最后一个ACK包，依然处于SYN-RCVD状态。
  • 站在服务端的角度，服务端会以为自己发送的SYN + ACK的包丢失，则会触发超时重传机制。**如果一直不成功，服务器会有一个针对超时重传的超时设置，超时之后会给客户端发送RTS报文并进入CLOSE阶段。**这么做是为了防止SYN泛洪攻击，此时客户端也应该会关闭连接。
    • SYN泛洪攻击（DoS攻击）：攻击者发送大量的TCP SYN报文段，而不完成第三次握手，服务器为大量的这种半开连接分配资源，最终导致服务器资源耗尽。
  • 如果当服务端处于SYN-RCVD状态下时，接收到客户端真实发送来的数据包时，会认为连接已建立，并进入ESTABLISHED状态。客户端在ESTABLISHED状态下发送数据包时，会携带上一个ACK的确认序号，所以哪怕客户端响应的ACK包丢了，服务端在收到这个数据包时，能够通过包内ACK的确认序号，正常进入ESTABLISHED状态。

为什么握手是三次，而挥手却要四次？

• TCP连接只需要三次握手的原因是：第二次握手过程中，服务器端发送给客户端的TCP报文是以SYN和ACK作为标志位的，SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端服务器收到了它的请求报文。SYN建立连接报文与ACK确认接收报文是在同一次握手当中传输的，所以三次握手不多也不少，正好让双方的信息互通。
• TCP释放连接时之所以需要四次挥手，是因为ACK确认接收报文和FIN释放连接报文是分别由第二次和第三次挥手传输的。这是因为在服务端接收到客户端释放连接请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，然后经过CLOSE-WAIT阶段处理好数据，准备好释放连接之后，才能返回FIN释放连接报文。

为什么客户端在TIME-WAIT阶段要等待2MSL？

确认服务器端是否接收到客户端发出的ACK确认报文：当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。（MSL是Maximum Segment Lifetime 一段TCP报文在传输过程中的最大生命周期。2MSL就是服务器端发出为FIN报文和客户端发出的ACK确认报文能保持有效的最大时长，一来一回刚好是2MSL）。

因为服务端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文。

• 如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文，客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时。
• 如果客户端在2MSL内没有收到来自服务器端的FIN报文，说明服务端正常的接收了ACK确认报文，客户端可以进入CLOSED阶段，完成四次挥手。

**让迟来的TCP报文在网络中消逝。**即防止让已失效的连接请求报文段出现在本次连接中。当客户端在发送完最有一个ACK报文后，经过2MSL就可以使本连接持续的时间内所产生的所有本文段都从网络中消失，可以使下一个新连接中不会出现这种旧的连接请求报文段。

TIME-WAIT阶段有什么问题？

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。

• 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
• 在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIME-WAIT超时的时间”的连接。

TCP保活机制？

保活机制就是判断对方是否在线，TCP对于非正常断开的连接是不能侦测到的，在TCP规范中是没有规定连接的保活功能的。

TCP保活机制的实现：通过保活计时器，当计时器被激发，连接一端将发送一个保活侦测报文，另一端接收报文的同时发送一个ACK作为响应。

• tcp_keepalice_time：7200，保活时间，默认7200s
• tcp_keepalice_intvl：75，保活时间间隔，默认75s
• tcp_keepalice_probes：9，保活探测数，默认9次

保活机制的过程：连接中启动保活功能的一端，在保活时间内连接处于非活动状态，则向对方发送一个保活探测报文，如果收到响应，则重置保活计时器，如果没有收到响应报文，则经过一个保活时间间隔后再次向对方发送一个保活探测报文，如果还没有收到响应报文，则继续，直到发送次数到达保活探测数，此时，对方主机将被确认为不可到达，连接被中断。

TCP和UDP的区别以及应用场景

TCP和UDP都是传输层的协议

**用户数据报协议UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有流量控制和拥塞控制，面向报文，支持一对一、一对多、多对一和多对多的交互通信。**UDP在网络拥堵的情况下无法进行流量控制、拥塞控制等避免网络拥堵的方法。此外，传输途中如果出现了丢包，UDP也不负责重发，甚至出现包的到达顺序混乱也没有纠正的功能。如果需要控制这些行为，那么必须交给实现了UDP的应用程序去自己处理，UDP只是提供作为传输层协议的基本功能。

UDP的应用场景：效率优先，要求网络通讯速度能尽量快，但是对准确性要求不是很高且对网络通讯质量要求不高的场景。例如：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是偶尔出现断续不是大问题，且完全可以不用重发机制）还有广播等。

---

传输控制协议TCP（Transmission Control Protocol）是面向连接的，提供可靠交付，有流量控制和拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块）。每条TCP连接只能是点对点（一对一）的，TCP充分实现了数据传输时各种控制功能，可以进行丢包的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些都是UDP没有的。此外，TCP作为一种面向连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。TCP通过检验和、序列号和确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

TCP应用场景：效率要求不高但准确性要求较高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高，例如：文件传输、邮件收发。TCP往往用于一些要求可靠的应用，例如HTTP、HTTPS、FTP（文件传输协议）和、SMTP（邮件传输协议）

TCP如何保证可靠传输

TCP主要通过以下方式来确保可靠性：**校验和、序列号与确认应答、超时重传、连接管理、流量控制、拥塞控制。**其中前三个属于差错控制。

• 校验和：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面加，最后取反得到校验和。

​ 发送方：在发送数据之前计算校验和并进行校验和的填充。

​ 接收方：收到数据后，对数据以同样的方式进行计算，求出校验和与发送方的进行对比。

​ 如果接收方对比校验和与发送方的不一致，那么数据一定传输有误。但一致也不能说明数据一定传输无误。

• 序列号与确认应答

  • 序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。
    • 序列号保证可靠性（当接收到的数据少了某个序号的数据时，能马上感知）
    • 保证数据的按时序到达
    • 提高效率，实现多次发送一次确认，且可以去除重复数据
  • 确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，也就是发送ACK报文。接收方对于按序到达的数据会进行确认，当标志位ACK=1时确认首部的确认字段有效。进行确认时，确认字段值表示这个值之前的数据都已经按序到达了。而发送方如果收到了已发送的数据的确认报文，则继续传输下一部分数据；而如果等待了一定时间还没有收到确认报文就会启动重传机制。

• 超时重传

  • 当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传（通常是在发出报文段后设定一个闹钟，到点了还没有收到应答则进行重传）。

  • 两种情况：数据丢包或者确认应答丢包

    

• 连接管理：TCP建立时的三次握手和四次挥手

• 流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。

  • 起因：接收端处理数据的速度是有限的，如果发送方发送数据的速度过快，导致接收端的缓冲区满，而发送方继续发送，就会造成丢包，继而引起丢包重传等一系列连锁反应。
  • 它是一个端对端的问题。

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

  • 起因：如果网络非常拥堵，此时再发送数据就会加重网络负担，可能发送端发送的数据超过了最大生存时间也没有到达接收方，产生丢包问题。为了引入TCP慢启动机制，先发送少量数据，类似探路，摸清当前的网络拥堵状态后，再决定按照多大的速度传送数据。
  • 防止过多的数据注入到网络中，是一个全局性的问题。

TCP中的滑动窗口（流量控制）

简介

TCP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。

滑动窗口解决的是流量控制的问题：如果接收端和发送端对数据包的处理速度不同，如何让双发达成一致。接收端的缓存数据是传输给应用层的，但是这个过程不及时，如果发送的速度太快，会出现接收端数据溢出。

窗口的概念

发送方的发送缓存内的数据都可以被分为4类：

• 1.已发送且已收到ACK
• 2.已发送但未收到ACK
• 3.未发送但允许发送
• 4.未发送但不允许发送
• 其中2和3都属于发送窗口

接收方的缓存数据分为3类：

• 1.已接收
• 2.未接收但准备接收
• 3.未接收且不准备接收
• 其中2属于接收窗口

窗口大小代表了设备一次能从对端处理多少数据，之后再传给应用层。缓存传给应用层的数据不能是乱序的，窗口机制保证了这一点。

滑动机制

• 发送窗口只有收到发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
• 接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当前面还有字节未接收但是收到了后面字节的情况下，窗口不会移动，并不会对后续字节的确认，以保证对端会对这些数据进行重传。

深入分析

• TCP连接是通过数据包和ACK实现的，我们作为第三者可以看到双方发包的过程，但是接收者在收到之前不知道发送方发的是什么，同样发送方在收到ACK前也不知道对方是否接收成功。
• 发送方没有接收到接收方的ACK，就不能向右滑动。假如发送方发了ABCD，只要接收方没有接收到A就不能滑动，这样就不会出现二者不同步的情况。
• 窗口的大小不能大于序号空间的一半，目的是为了不让两个窗口出现交迭。例如总大小为7，每个窗口的大小都是4。接收窗口应当滑动4，但是只剩下3个序号。
• 发送方发出四个数据ABCD，接收方都接收完毕后向右滑动，但是回复的ACK包全部丢失，发送方未收到任何的ACK，timeout之后会重发ABCD，此时接收方按累计确认的原则，收到ABCD后只会重发D的ACK，发送方收到后直接向右滑动。

动态演示

首先发送端发送ABCD四个包，但AB丢失，只有CD到达接收端。

接收端没有接收到A，所以不回复ACK包。发送端重传ABCD，这次全部到达。

接收端先获得的A，发送A的ACK包，但是中途丢失；获得B后，根据累计确认原则，发D的ACK包，然后接收端窗口滑动4位。再次获得CD后，连续回复两个D的ACK包。

发送端接收到D的ACK包，说明4个包对方都已经收到，发送端窗口滑动4位。发送EFGH包，其中G包丢失。现在整个序列的状态是：ABCD已发送，EFGH是已发送未确认，I-S是不能发送。

接收端先收到E，发E的ACK包。然后收到F，发F的。根据累计确认原则：没有收到G，还是发F的，收到H，还是发F的。不巧的是三个F的ACK包全部丢失。

发送端收到了E的ACK包，发送窗口向右移一位，然后再发送FGHI，其中F丢失。

接收端先获得I，但是没有G，只好先发送F的ACK包。然后相继收到了GH包。

接收端根据累计确认，连发两个I包，其中H对应的丢失。接收窗口向右滑动4位。

发送端接收到I的ACK包，向右滑动4位，后面不再分析

TCP拥塞控制详解

简介

拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不到过载。拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。

其实现一般有四种方法：慢开始（slow-start）、拥塞避免（congestion avoidance）、快重传（fast retransmit）和快恢复（fast recovery）

发送方维持着一个拥塞窗口cwnd的状态变量。拥塞窗口大小取决于网络的拥塞程度，并且动态的发生变化。发送方让自己的发送窗口的大小等于拥塞窗口的大小。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，就把拥塞窗口增大一些，以便把更多的分组发送出去；对应的网络出现拥塞，拥塞窗口就小一些，以减少注入到网络中的分组数。

慢开始：指数增长cwnd

• 当主机开始发送数据时，如果立即将大量的数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此最好的方法就是先发送一小段数据发送先探测一下，由小到大逐渐增大发送窗口。通常在刚开始发送报文段的时候，先把拥塞窗口cwnd设置为一个MSS（最大报文段，收发双方协商通信时每一个报文段所能承载的最大数据长度）的数值，在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。

  

  每经过一个轮次，拥塞窗口的cwnd就加倍。一个传输轮次所经历的时间就是往返时间RTT。不过传输轮次强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。

  慢开始的慢不是说cwnd的增长速率慢，而是指TCP开始发送报文段时cwnd = 1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再逐渐增大cwnd。

  为了防止cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。

  • 当 cwnd < ssthresh 时，使用上述的慢开始算法。
  • 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
  • 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。

拥塞避免算法：指数变线性

• 让拥塞窗口缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口cwnd就按照线性缓慢的增长，比慢开始的指数增长速率慢的多。
• 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是发送方没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

快重传

• 如果发送方设置的超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。这时，TCP马上把拥塞窗口 cwnd 减小到1，并执行慢开始算法，同时把慢开始门限值ssthresh减半。这是不使用快重传的情况。

• 快重传算法首先要求接收方每收到一个失序的报文就立即发出重复确认（为了使发送方乘早知道有报文段没有到达对方），而不是要等自己发送数据再捎带确认。一旦发送方接连收到三个重复确认，就应当立刻重传对方尚未收到的之前的报文段，而不是等待报文段设置的重传计时器到期。

  

  接收方收到了M1和M2后都分别发出了确认，现在假定接收方没有收到M3但接着收到了M4。显然接收方不能确认M4，M4是失序的报文段，根据可靠传输原理，接收方可以什么也不做，也可以在适当时机发送一次对M2的确认。但是快重传算法规定：**接收方应该及时发送对M2的重复确认，这样做可以让发送方早知道自己发送的M3没有到达接收方。**由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

快恢复

• 与快重传配合的还有快恢复算法，其主要过程是：

  • 当发送方连续收到三个重复确认，就执行乘法减小的算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。
  • 由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（cwnd不设置为1），而是把cwnd设置为跟现在慢开始门限ssthresh一样的数值，并执行拥塞避免算法（加法增大），使拥塞窗口缓慢的线性增大。

• 也有的快恢复实现是把开始时的拥塞窗口cwnd值再增大一点，即等于 ssthresh + 3 X MSS 。这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络的资源而是停留在接收方的缓存中，可见现在网络中并不是堆积了分组而是减少了三个分组。因此可以适当把拥塞窗口扩大了些。

• 在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。采用这样的拥塞控制方法使得TCP的性能有明显的改进。

• 接收方根据自己的接收能力设定了接收窗口rwnd，并把这个窗口值写入TCP首部中的窗口字段，传送给发送方。因此，接收窗口又称为通知窗口。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口rwnd。

  • 发送方窗口的上限值 = Min [ rwnd, cwnd ]
  • 当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值。
  • 当cwnd < rwnd 时，则是网络的拥塞限制发送方窗口的最大值。

TCP的粘包拆包问题

起因

TCP是个面向字节流协议，是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是TCP拆包粘包问题。

出现场景

假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下五种情况：

• 服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有发生粘包和拆包。
• 服务端一次接受了两个数据包，D1和D2粘在了一起，被称为TCP粘包。
• 服务端分两次读取到了两个数据包，第一次读取到了完整的D1包和D2的部分内容，第二次读取到了D2包的剩余内容，被称为TCP拆包。
• 服务端分两次读取到了两个数据包，第一次读取到了D1包的部分内容，第二次读取到了D1包的剩余内容和D2包的全部内容。
• 如果服务端TCP的接收窗口非常小，可能会有服务端分多次才能将D1和D2包接收完全，发生多次拆包。

造成原因

• 要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
• 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
• 待发送数据大于MSS（最大报文长度），TCP在传输前将会进行拆包。必须保证TCP报文长度-TCP头部长度 > MSS

粘包和拆包解决思路

由于TCP是无法理解上层的业务数据，所以解决只能从上层的应用协议栈来解决，根据业界的主流协议的解决方案：

• 消息定长：发送端将每个数据包封装为固定长度（不够通过0补充），这样接收端每次接受缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
• 设置消息边界：服务端从网络流中按消息边界分离出消息内容，在包尾增加回车换行符进行分割，例如FTP协议。
• 将消息分为消息头和消息体：消息头中包含消息的总长度信息，发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

UDP有粘包的问题吗

TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于字节流的传输，基于流的传输不认为消息是一条的，而是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护边界的，接收方一次只接受一条独立的信息，不存在粘包的问题。

IP协议

IP（Internet Protocol，网际互联协议）协议是TCP/IP中网络层协议。出现的的目的是提高网络的可扩展性，实现大规模、异构网络的互联互通。根据端到端的设计原则，IP只为主机提供一种无连接、不可靠的、尽力而为的数据包传输服务。

IP分组的转发规则：当IP数据包经由路由器转发时，如果目标网络与本地路由器直接相连，则直接将数据包交付给目标主机，称为直接交付；否则路由器通过路由表查找路由信息，并将数据包转交给指明的下一跳路由器，这称为间接交付。路由器在间接交付中，若路由表中有到达目标网络的路由，则把数据包传送给路由表指明的下一跳路由器；如果没有路由，但是路由表中有一个默认路由，则把数据报传给指明的默认路由器；如果两者都没有，则丢弃数据包并报告错误。

五类IP地址

A类地址：第一个字节0开头，其余7位为网络地址，后3个字节为主机地址。起始地址为1-126，范围是1.0.0.1—126.225.255.254，A类保留给政府机构。

• 10.0.0.0到10.255.255.255是私有地址（互联网上不使用，被用在局域网络中的地址）
• 127.X.X.X是保留地址，用作循环测试

B类地址：第一个字节10开头，前2个字节为网络地址，后2个字节为主机地址。起始地址为128-191，范围是128.0.0.1—191.255.255.254，B类分配给中等规模的公司。

• 172.16.0.0—172.31.255.255是私有地址
• 169.254.X.X是保留地址。如果你的IP地址是自动获取IP地址，而你在网络上又没有找到可用的DHCP服务器。就会得到其中一个IP。
• 191.255.255.255是广播地址，不用来分配。

C类地址：C类地址第1字节、第2字节和第3个字节为网络地址，第4个个字节为主机地址。另外第1个字节的前三位固定为110。C类地址范围： 192.0.0.1—223.255.255.254。C类地址中192.168.X.X是私有地址。C类地址是给个人使用的。

D类地址：D类地址不分网络地址和主机地址，它的第1个字节的前四位固定为1110。 D类地址范围： 224.0.0.1—239.255.255.254。一般用来组播。

E类地址：也不分网络地址和主机地址，它的第1个字节的前五位固定为11110。 E类地址范围： 240.0.0.1—255.255.255.254。一般用来实验。

计算机设置IP的参数

IP地址：192.168.1.2-254任何一个都可

子网掩码：255.255.255.0

• 用于屏蔽IP地址的一部分以区别网络标识和主机表示，并说明该IP地址是在局域网上还是在远程网上；用于将一个大的IP网络划分为若干小的子网络。
• 使用子网是为了减少IP的浪费，随着互联网的发展，越来越多的网络产生，有的网络多则几百台，少则只有几台，这样会浪费很多的IP地址，所以要划分子网，使用子网可以提高网络应用的效率。

默认网关：192.168.1.1

• 默认网关是子网与外网连接的设备，通常是一个路由器，当一台计算机发送信息时，根据发送信息的目标地址，通过子网掩码来判定目标主机是否在本地子网中，如果目标主机在本地子网中，则直接发送即可。如果目标不在本地子网中则将该信息送到缺省网关/路由器，由路由器将其转发到其他网络中，进一步寻找目标主机。

DNS或者地区通用DNS

ARP协议

**ARP全称地址解析协议。在以太网环境中，数据的传输所依赖的是MAC地址而非IP地址，将已知的IP地址转换为MAC地址的工作就是由ARP协议来完成的。**局域网中，网络中实际传输的是帧，帧里面是由目标主机的MAC地址的。在以太网中，一个主机和另一个主机进行直接通信，必须知道目标主机的MAC地址。

在任何时候，一台主机有IP数据报文发送给另一台主机，它都要知道接收方的逻辑（IP）地址。但是IP地址必须封装成帧才能通过物理网络。这就意味着发送方必须有接收方的物理（MAC）地址，因此需要完成逻辑地址到物理地址的映射。而ARP协议可以接受来自IP协议的逻辑地址，将其映射为相应的物理地址，然后把物理地址递交给数据链路层。

ARP映射方式

静态映射

手动创建一张ARP表，把逻辑（IP）地址和物理地址关联起来。这个ARP表存储在网络中的每一台机器上。例如，知道其机器的IP地址但不知道其物理地址的机器就可以通过查ARP表找出对应的物理地址。

这样做有一定的局限性：

• 机器可能更换NIC（网络适配器），结果变成一个新的物理地址。
• 在某些局域网中，每当计算机加电时，他的物理地址就要改变一次。
• 移动电脑可以从一个物理网络转移到另一个物理网络，引起物理地址的改变。

要想避免这些情况，就必须定期维护更新ARP表，十分麻烦且会影响网络性能。

动态映射

每次只要机器知道另一台机器的逻辑（IP）地址，就可以使用协议找出相对应的物理地址。ARP实现了把逻辑地址映射为物理地址，RARP实现了把物理地址映射为逻辑地址。

ARP流程

ARP请求：当主机需要找出这个网络中另一个主机的物理地址时，它就可以发送一个ARP请求报文，这个报文包装了发送方的MAC地址和IP地址以及接收方的IP地址。因为发送方并不知道接收方的接收地址，所以这个查询会在网络层中进行广播。

ARP响应：局域网中的每一台主机都会接受并处理这个ARP请求报文，然后进行验证，查看接收方的IP地址是不是自己的地址，只有验证成功的主机才会返回一个ARP响应报文，这个响应报文包含接收方的IP地址和物理地址。这个报文利用收到的ARP请求报文中的请求方物理地址以单播的方式直接发送给ARP请求报文的请求方。

扩展：cookie和session

cookie：一小段文本信息，服务器单从网络连接上无法知道客户身份，所以服务器给客户端颁发一个通行证。每次进行访问的时候都必须携带自己的通行证，这样服务器就能从通行证上确认客户身份了。服务器还可以根据需要修改cookie的内容。

session：session是服务端使用的一种记录客户端状态的机制，使用比cookie简单，相应的也增加了服务器的存储压力。其在用户第一次访问服务器的时候自动创建（纯访问HTML和IMAGE等静态资源不会生成），如果未生成可以使用request.getSession(true)强制生成session，session生成后，只要用户继续访问，服务器就会更新session的最后访问时间，并维护该session。session默认30分钟不使用就会销毁，可以通过setMaxInactiveInterval来设置时间。

为什么要有session？

由于HTTP协议是无状态的，客户端向服务端发送一个request，然后服务器返回一个相应的response，之后这个连接就会被关闭，两者也没有任何关系了，也就是服务器中不会存储此次请求的有关信息，再次请求时服务器就无法知道这次请求和上次请求是否是一个客户了。所以我们就需要采用会话session来记录这次连接的信息了。

一个客户端访问服务器时，可能会在这个服务器的多个页面之间不断刷新、反复连接同一个页面或者向一个页面提交信息，有了session的记录，服务器就可以知道这就是同一个客户端在完成这些动作。

cookie和session的区别

• 存储位置不同：
  • cookie的数据信息存放在客户端浏览器上，别人可以分析存放在本地cookie并进行cookie欺骗，是不安全的。
  • session的数据信息存放在服务器上，对客户端是不可见的，不存敏感信息泄露的风险。
• 生命周期不同：
  • 一次session的生存周期就是浏览器关闭，一关session就消失。
  • cookie则是预先设置生命周期，或永久的保留在本地文件中。
• 存储容量不同：
  • 单个cookie保存的数据 <= 4KB，一个站点最多保存20个Cookie
  • 对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制
• 存储方式不同：
  • cookie中只能保存ASCII字符串，并需要通过编码的方式存储为Unicode字符或者二进制数据
  • session中能够存储任何类型的数据，包括且不限于String、Integer、List、Map等
• 有效期不同：
  • 可以通过代码来设置cookie的属性，达到使cookie长期有效的效果。
  • session依赖JSESSIONID的cookie，而cookie JSESSIONID的过期时间默认为-1，只要关闭窗口该session就会失效，因此session不能达到长期有效的效果。
• 服务器压力不同：

  • cookie保存在客户端，不会占用服务器资源，对于并发用户十分多的网站，cookie是很好的选择。

  • session是保管在服务器端的，每个用户都会产生一个session。假如并发访问的用户十分多，会产生十分多的session，耗费大量内存。

幂等性

**幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。**在增删改查4个操作中，尤为注意就是增加或者修改，查询对于结果是不会有改变的，删除只会进行一次，用户多次点击产生的结果一样，修改在大多场景下结果一样，增加在重复提交的场景下会出现。其中对HTTP常见请求方法来说，GET、PUT、DELETE都是幂等的，而POST则不是幂等的

了解：TCP/IP协议工作流程

• 在源主机上，应用层将一串应用数据流传送给传输层。
• 在传输层将应用层的数据流截成分组，并加上TCP报头形成TCP段，送交网络层。
• 在网络层给TCP段加上包括源、目的主机IP地址的IP报头，生成一个IP数据包，并将IP数据包送交给网络层。
• 链路层在其MAC帧的数据部分装上IP数据包，再加上源、目的主机的MAC地址和帧头，并根据其目的的MAC地址，将MAC帧发往目的主机或IP路由器。
• 在目的主机，链路层将MAC帧的帧头去掉，并将IP数据包送交给网络层。
• 网络层检查IP头，如果报头中校验和与计算结果不一致，则丢弃该IP数据包；如果校验和计算结果一致，则去掉IP报头，将TCP段送交给运输层。
• 传输层检查顺序号，判断是否是正确的TCP分组，然后检查TCP报头数据。若正确，则向源主机发送确认信息；若不正确或丢包，则向源主机要求重发信息。
• 在目的主机，传输层去掉了TCP报头，将排好顺序的分组组成应用数据流送给应用程序。这样目的主机接收到的来自源主机的字节流，就像是直接接收来自源主机的字节流一样。