计算机网络之上篇

最新推荐文章于 2024-07-08 16:47:57 发布

海岸星的清风

最新推荐文章于 2024-07-08 16:47:57 发布

阅读量442

点赞数 1

文章标签：计算机网络网络服务器

本文链接：https://blog.csdn.net/weixin_42461320/article/details/129726144

版权

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

浏览器解析url；
生成一个http请求协议包，把协议包的发送委托给操作系统；
操作系统在发送协议包之前先要获取服务器的IP地址。如果在本地的浏览器缓存、操作系统缓存或者hosts文件中存在对应的IP地址，就不需要再访问本地的DNS服务器了。如果不存在，访问本地的DNS服务器，由本地DNS服务器对进行递归访问，即按照层级向下访问，最后得到IP地址；
得到ip地址后。进行TCP连接，三次握手；
握手之后，把请求层层封装，通过网卡将数据发送到交换机。交换机会进行校验以及查找交换表转发，到达路由器。路由器把MAC层扒皮，查看目的ip，然后根据路由表选择下一跳，再进行MAC层封装。重复这个过程，最后到达服务器；
到达服务器后，会对数据包进行扒皮并且校验。使用FCS校验码校验二进制序列的正确性。在MAC层看目的MAC是不是自己，在网络层看目的ip是不是自己，同时知道上层协议是TCP还是UDP协议。在TCP中知道这是一个什么保文，请求保文、响应报文还是结束连接的报文。通过端口号知道这是交给那么应用进程的；
应用进程知道你访问的是什么资源，那么就给客户端返回一个Http响应协议包，把资源封装在其中。通过同样的流程把数据返回给客户端；
浏览器拿到数据后，对数据进行渲染，解码，变成了一个页面显示在浏览器上。

HTTP状态码

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

GET和POST的区别

GET和POST是HTTP协议中的两种发送请求的方法。GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器处理数据能力的限制，导致他们在应用过程中体现出一些不同。

GET主要是用来获取新的网页；POST用作向服务器传递用户的表单数据，如用户名、密码、留言等等；
GET把参数包含在URL中，POST通过消息体传递参数；
GET请求在URL中传送的参数是有长度限制的，而POST通过消息体传递的参数没有长度限制。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留；
对参数的数据类型，GET只接受ASCII字符，而POST没有限制；
GET产生一个TCP数据包，而POST产生两个TCP数据包。

对于GET请求，浏览器会把请求头和消息体一并发送出去，服务器响应200 ok（返回数据）；而对于POST请求，浏览器先发送请求头，服务器响应100 continue后，浏览器再发送消息体，服务器响应200 ok（返回数据）。在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

Cookie Session

Cookie和Session的区别？

作用范围不同，Cookie 保存在客户端，Session 保存在服务器端。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
隐私策略不同，Cookie 存储在客户端，容易被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
存储大小不同，单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限，但出于对服务器的性能考虑，Session 内不要存放过多的数据，并且需要设置 Session 删除机制。

客户端和服务端能否更改cookie？

Cookie并不提供修改、删除操作。

如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。

如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

int maxAge：该Cookie失效的时间，单位秒。

如果为正数，则该Cookie在maxAge秒之后失效；

如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie；

如果为0，表示删除该Cookie；

默认为-1。

HTTPS特性

HTTP 与 HTTPS 有哪些区别？

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
HTTP 的端口号是 80，HTTPS 的端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS 如何解决HHTP的三个安全风险？

混合加密的方式实现信息的机密性，解决了窃听的风险；
将服务器公钥放入到数字证书中，解决了冒充的风险；
摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，保证传输过程的安全性。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据，保证通信过程的效率。

采用「混合加密」的方式的原因：

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

HTTPS 的优缺点

优点

HTTPS传输数据过程中使用密钥进行加密，所以安全性更高；
HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器。

缺点

HTTPS握手阶段延时较高：由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加；
HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；另一方面由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高。

HTTPS连接建立过程及SSL工作流程

SSL/TLS 协议基本流程（rsa原理）：

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段，SSL/TLS 的「握手阶段」涉及四次通信。SSL/TLS 协议建立的详细流程：

客户端给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
服务器确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务器。
服务器使用自己的私钥，获取客户端发来的随机数（Premaster secret）。
客户端和服务器根据约定的加密方法，使用前面的三个随机数，生成”对话密钥”（session key），用来加密接下来的整个对话过程。

HTTP报文

请求报文

HTTP请求报文由请求行（request line）、请求头部（header）、空行和消息体四个部分组成。

请求报文分为两种，GET和POST：

GET

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host:img.mukewang.com
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept:image/webp,image/*,*/*;q=0.8
Referer:http://www.imooc.com/
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8
空行
请求数据为空

POST

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
空行
name=Professional%20Ajax&publisher=Wiley

请求行用来说明请求类型，要访问的资源以及所使用的HTTP版本。

GET说明请求类型为GET，/562f25980001b1b106000338.jpg(URL)为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。

请求头部紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息。

HOST，给出请求资源所在服务器的域名。
User-Agent，HTTP客户端程序的信息，该信息由你发出请求使用的浏览器来定义，并且在每个请求中自动发送等。
Accept，说明用户代理可处理的媒体类型。
Accept-Encoding，说明用户代理支持的内容编码。
Accept-Language，说明用户代理能够处理的自然语言集。
Content-Type，说明实现主体的媒体类型。
Content-Length，说明实现主体的大小。
Connection，连接管理，可以是Keep-Alive或close。

空行，请求头部后面的空行是必须的，即使第四部分的请求数据为空，也必须有空行。

请求数据也叫主体，可以添加任意的其他数据。

响应报文

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8
空行
<html>
      <head></head>
      <body>
            <!--body goes here-->
      </body>
</html>

状态行由HTTP协议版本号，状态码，状态消息三部分组成。第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为OK。

消息报头，用来说明客户端要使用的一些附加信息。第二行和第三行为消息报头，Date：生成响应的日期和时间；Content-Type：指定了MIME类型的HTML(text/html)，编码类型是UTF-8。

空行，消息报头后面的空行是必须的。

响应正文，服务器返回给客户端的文本信息。空行后面的html部分为响应正文。

HTTP/1.1、HTTP/2、HTTP/3的演变

HTTP/1.1

HTTP/1.1优点

简单

HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，很简单。
灵活和易于扩展

HTTP协议里的各类请求方法、状态码、头字段等都是可以自定义扩展的；同时 HTTP 工作在应用层，下层可以随意变化。
应用广泛和跨平台

HTTP/1.1缺点

无状态

服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，但是会导致它在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。

无状态的问题解决方法有cookie/session/token，Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
明文传输

明文意味着在传输过程中的信息是可阅读的，通过F12 控制台或 Wireshark 抓包都可以直接查看，方便调试，但是也导致了信息泄露。明文传输的问题在https协议中得到了解决。
不安全

HTTP 比较严重的缺点就是不安全：通信使用明文传输，内容可能会被窃听；不验证通信方的身份，因此有可能遭遇伪装；无法证明报文的完整性，所以有可能已遭篡改。

HTTP 的安全问题，可以用 HTTPS的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

HTTP/1.1的性能

长连接

HTTP/1.0 规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。 TCP连接的建立需要三次握手，通信开销比较大。所以，HTTP/1.0版本的性能比较差。

为了解决上述 TCP 连接问题，HTTP/1.1提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器的负载。

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。当然，如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。

管道网络传输

HTTP/1.1 采用了长连接的方式，这使得管道网络传输成为了可能。即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应，如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞，造成「队头阻塞」。所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

队头阻塞

当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。

HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

HTTP/2 做了什么优化？

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

那 HTTP/2 相比 HTTP/1.1 性能上的改进：

头部压缩

HTTP/2 会压缩头，如果同时发出多个请求，如果请求头是一样的或是相似的，那么会消除重复的部分。

这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是采用了二进制格式，头信息和数据体都是二进制（统称为帧：头信息帧和数据帧）。收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，增加了数据传输的效率。

数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

在 HTTP/2 中每个请求或相应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号（Stream ID），不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息。

多路复用

HTTP/2 可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。

服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

HTTP/2的缺陷

HTTP/2 还是存在队头阻塞的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP这一层。

HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用。当前一个字节数据没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这一个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。

所以，一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/3 做了哪些优化？

HTTP/1.1 和 HTTP/2 都有队头阻塞的问题：

HTTP/1.1 中的管道虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等相应完这个请求后，才能处理下一个请求，这属于 HTTP 层队头阻塞。
HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP。

UDP的发生是不管顺序，也不管丢包的，所以不会出现像 HTTP/2 队头阻塞的问题。虽然 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。QUIC 有以下 3 个特点：

无队头阻塞

QUIC 连接上当某个数据流发生丢包时，只会阻塞这个数据流，其他数据流不会受到影响，因此不存在队头阻塞问题。这与 HTTP/2 不同，HTTP/2 只要某个数据流中的数据包丢失了，其他数据流也会因此受影响。

更快的连接建立

但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商。

连接迁移

基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接，那么当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接。而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。

而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题，因为有的网络设备是会丢掉 UDP 包的，而 QUIC 是基于UDP 实现的，那么如果网络设备无法识别这个是 QUIC 包，那么就会当作 UDP包，然后被丢弃。

所以，HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。

UDP TCP

TCP 和 UDP 区别：

连接

TCP 是面向连接的传输层协议，传输数据前先要建立连接。
UDP 是不需要连接，即刻传输数据。

服务对象

TCP 是一对一的两点服务，即一条连接只有两个端点。
UDP 支持一对一、一对多、多对多的交互通信

可靠性

TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
UDP 是尽最大努力交付，不保证可靠交付数据。

拥塞控制、流量控制

TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

首部开销

TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

传输方式

TCP 是流式传输，没有边界，但保证顺序和可靠。
UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

分片不同

TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层。

TCP 和 UDP 应用场景：

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

FTP 文件传输；
HTTP / HTTPS；

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

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

TCP的头部

aHR0cHM6Ly9jZG4uanNkZWxpdnIubmV0L2doL3hpYW9saW5jb2Rlci9JbWFnZUhvc3QyLyVFOCVBRSVBMSVFNyVBRSU5NyVFNiU5QyVCQSVFNyVCRCU5MSVFNyVCQiU5Qy9UQ1AtJUU0JUI4JTg5JUU2JUFDJUExJUU2JThGJUExJUU2JTg5JThCJUU1JTkyJThDJUU1JTlCJTlCJUU2JUFDJUExJUU2JThDJUE1JUU2JTg5JThCLzYuanBn (1053×828) (csdnimg.cn)

序列号：在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。

确认应答号：指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。

控制位：

ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。
RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。# 键入网址到网页显示，期间发生了什么？

浏览器解析url；
生成一个http请求协议包，把协议包的发送委托给操作系统；
操作系统在发送协议包之前先要获取服务器的IP地址。如果在本地的浏览器缓存、操作系统缓存或者hosts文件中存在对应的IP地址，就不需要再访问本地的DNS服务器了。如果不存在，访问本地的DNS服务器，由本地DNS服务器对进行递归访问，即按照层级向下访问，最后得到IP地址；
得到ip地址后。进行TCP连接，三次握手；
握手之后，把请求层层封装，通过网卡将数据发送到交换机。交换机会进行校验以及查找交换表转发，到达路由器。路由器把MAC层扒皮，查看目的ip，然后根据路由表选择下一跳，再进行MAC层封装。重复这个过程，最后到达服务器；
到达服务器后，会对数据包进行扒皮并且校验。使用FCS校验码校验二进制序列的正确性。在MAC层看目的MAC是不是自己，在网络层看目的ip是不是自己，同时知道上层协议是TCP还是UDP协议。在TCP中知道这是一个什么保文，请求保文、响应报文还是结束连接的报文。通过端口号知道这是交给那么应用进程的；
应用进程知道你访问的是什么资源，那么就给客户端返回一个Http响应协议包，把资源封装在其中。通过同样的流程把数据返回给客户端；
浏览器拿到数据后，对数据进行渲染，解码，变成了一个页面显示在浏览器上。