标签：请求 报文 TCP 计算机网络 服务器 连接 客户端

1 计算机网络的各层协议及作用？TODO

计算机网络体系可以大致分为一下三种，OSI七层模型、TCP/IP四层模型和五层模型。

• OSI七层模型：大而全，但是比较复杂、而且是先有了理论模型，没有实际应用。
• TCP/IP四层模型：是由实际应用发展总结出来的，从实质上讲，TCP/IP只有最上面三层，最下面一层没有什么具体内容，TCP/IP参考模型没有真正描述这一层的实现。
• 五层模型：五层模型只出现在计算机网络教学过程中，这是对七层模型和四层模型的一个折中，既简洁又能将概念阐述清楚。
  

TCP/IP五层模型：应用层、传输层、网络层、数据链路层、物理层：

• 应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS、HTTP协议、SMTP协议等。
• 传输层：有时也译为传输层，向主机进程提供通用的数据传输服务 。该层主要有以下两种协议：
  • TCP：提供面向连接的、可靠的数据传输服务；
  • UDP：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性。
• 网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
• 数据链路层：数据链路层通常简称为链路层。 将网络层传下来的IP数据包组装成帧 ，并再相邻节点的链路上传送帧。
• 物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。

2 TCP & UDP

UDP 和 TCP 的特点与区别?

• 用户数据报协议 UDP（User Datagram Protocol）
  • 无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。
• 传输控制协议 TCP（Transmission Control Protocol）
  • 面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是 点对点的（一对一） 。

UDP 和 TCP 对应的应用场景是什么？

TCP 用于在传输层有必要实现可靠传输的情况，UDP 用于对高速传输和实时性有较高要求的通信。TCP和 UDP 应该根据应用目的按需使用。

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

• FTP文件传输
• HTTP / HTTPS

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

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

TCP协议如何保证可靠性？

TCP主要提供了 检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制 和 流量控制 等方法实现了可靠性传输。

• 检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
• 序列号/确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

详细讲一下TCP的滑动窗口？

在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。

TCP 协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。

为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。

滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。

可以看到滑动窗口起到了一个 限流 的作用，也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率，而 滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。

详细讲一下拥塞控制？

TCP 一共使用了四种算法来实现拥塞控制：

• 慢开始 (slow-start)；
• 拥塞避免 (congestion avoidance)；
• 快速重传 (fast retransmit)；
• 快速恢复 (fast recovery)。

3 三次握手 & 四次挥手

重要字段

• 序号(sequence number)：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

• 确认号（acknowledgement number）：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。

• 标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：

  • URG：紧急指针（urgent pointer）有效。
  • ACK：确认序号有效。（区分确认号ack）
  • PSH：接收方应该尽快将这个报文交给应用层。
  • RST：重置连接。
  • SYN：发起一个新连接。
  • FIN：释放一个连接。

那么这些字段有什么作用呢？

seq序号、ack序号：用于确认数据是否准确，是否正常通信。

标志位：用于确认/更改连接状态。

三次握手

简述 TCP 三次握手过程

• 第一次握手：客户端请求建立连接，向服务端发送一个同步报文（SYN=1），同时选择一个随机数 seq = x 作为初始序列号，并进入SYN_SENT状态，等待服务器确认。
• 第二次握手：服务端收到连接请求报文后，如果同意建立连接，则向客户端发送同步确认报文（SYN=1，ACK=1），确认号为 ack = x + 1，同时选择一个随机数 seq = y 在这里插入代码片作为初始序列号，此时服务器进入SYN_RECV状态。
• 第三次握手：客户端收到服务端的确认后，向服务端发送一个确认报文（ACK=1），确认号为 ack= y + 1，序列号为 seq = x + 1，客户端和服务器进入ESTABLISHED状态，完成三次握手。

理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

为什么需要三次握手，而不是两次？

• 防止已过期的连接请求报文突然又传送到服务器，因而产生错误和资源浪费。
  • 客户端发送 A 报文段请求建立连接，由于网络延时未到达服务器
  • 客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随和客户端在分别收到对方确认报文后进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。
  • 此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。
• 三次握手才能让双方均确认自己和对方的发送和接收能力都正常。
  • 第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；
  • 第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
  • 第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
• 告知对方自己的初始序号值，并确认收到对方的初始序号值。
  • TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中 维护了序号字段和确认序号字段 ，通过
    这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。
  • 这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

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

因为三次握手已经可以确认

• 双方的发送接收能力正常
• 双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，

也就无需再第四次握手了。

• 第一次握手：服务器可以确认自己的接收能力和对方的发送能力正常；
• 第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常。客户端认为连接
  已建立。
• 第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常。此时双方均建立连接，可以正常通信。

四次挥手

简述 TCP 四次挥手过程

• 第一次挥手：客户端向服务端发送 连接释放报文（FIN=1） ，主动关闭连接，同时等待服务端的确认。
  • 序列号 seq = m，即客户端上次发送的报文的最后一个字节的序号 + 1
• 第二次挥手：服务端收到连接释放报文后，立即发出 确认报文（ACK=1） ，序列号 seq = k，确认号 ack = m + 1。
  • 这时 TCP 连接处于半关闭状态，即客户端到服务端的连接已经释放了，但是服务端到客户端的连接还未释放。这表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。
• 第三次挥手：服务端向客户端发送 连接释放报文（FIN=1，ACK=1） ，主动关闭连接，同时等待 A的确认。
  • 序列号 seq = p，即服务端上次发送的报文的最后一个字节的序号 + 1。
  • 确认号 ack = m + 1，与第二次挥手相同，因为这段时间客户端没有发送数据。
• 第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = m + 1，确认号为 ack = p + 1。
• 此时，客户端就进入了 TIME-WAIT 状态 。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命） 的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态。可以看到，服务端结束 TCP 连接的时间要比客户端早一些。

为什么连接的时候是三次握手，关闭的时候却是四次握手？

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段.接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。

服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？

• 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
  • 第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传FIN/ACK报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。
  • MSL 是 报文段在网络上存活的最长时间 。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端 重传的 FIN/ACK 报文 ，然后客户端重传一次 ACK 报文， 并重新启动 2MSL 计时器 。如此保证服务端能够正常关闭。
  • 如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。
• 防止已失效的连接请求报文段出现在之后的连接中。
  • TCP 要求在 2MSL 内不使用相同的序列号 。客户端在发送完最后一个 ACK 报文段后，再经过时间2MSL，就可以 保证本连接持续的时间内产生的所有报文段都从网络中消失 。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。

如果已经建立了连接，但是客户端出现故障了怎么办？

或者说，如果三次握手阶段、四次挥手阶段的包丢失了怎么办？如“服务端重发 FIN丢失”的问题。

简而言之，通过 定时器 + 超时重试机制 ，尝试获取确认，直到最后会自动断开连接。

具体而言，TCP 设有一个 保活计时器 。 服务器每收到一次客户端的数据，都会重新复位这个计时器，时间通常是设置为 2 小时 。若 2 小时还没有收到客户端的任何数据，服务器就开始重试： 每隔 75 分钟 发送一个探测报文段，若一连发送 10 个 探测报文后客户端依然没有回应，那么服务器就认为连接已经断开了。

TIME-WAIT 状态过多会产生什么后果？怎样处理？

从服务器来讲，短时间内关闭了大量的Client连接，就会造成服务器上 出现大量的TIME_WAIT连接 ，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。

从客户端来讲 ，客户端TIME_WAIT过多，就会 导致端口资源被占用 ，因为端口就65536个，被占满就会导致无法创建新的连接。

解决办法：服务器可以设置 SO_REUSEADDR 套接字 选项来避免 TIME_WAIT状态，此套接字选项告诉内核，即使此端口正忙（处于TIME_WAIT状态），也请继续并重用它。

TIME_WAIT 是服务器端的状态?还是客户端的状态?

TIME_WAIT 是主动断开连接的一方会进入的状态 ，一般情况下，都是客户端所处的状态;服务器端一般设置不主动关闭连接。

4 HTTP协议

HTTP协议的特点？

• HTTP允许传输 任意类型 的数据。传输的类型由 Content-Type 加以标记。
• 无状态 。对于客户端每次发送的请求，服务器都认为是一个新的请求，上一次会话和下一次会话之间没有联系。
• 支持客户端/服务器模式。

HTTP 和 HTTPS 的区别？

HTTP报文格式（分为HTTP请求和HTTP响应）？

HTTP请求由 请求行、请求头部、空行和请求体 四个部分组成。

• 请求行 ：包括请求方法，访问的资源URL，使用的HTTP版本。GET和POST 是最常见的HTTP方法，除此以外还包括 DELETE、HEAD、OPTIONS、PUT、TRACE 。
• 请求头 ：格式为“属性名:属性值”，服务端根据请求头获取客户端的信息，主要有**cookie、host、connection、accept-language、accept-encoding、user-agent** 。
• 请求体：用户的请求数据如用户名，密码等。

请求报文示例：

POST /xxx HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 请求体

HTTP响应也由四个部分组成，分别是： 状态行、响应头、空行和响应体 。

• 状态行：协议版本，状态码及状态描述。
• 响应头：响应头字段主要有 connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires 。
• 响应体：服务器返回给客户端的内容。

HTTP常见的状态码有哪些？

• 200：服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
• 301 ： (永久移动) 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD请求的响应)时，会自动将请求者转到新位置。
• 302：(临时移动) 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
• 400 ：客户端请求有语法错误，不能被服务器所理解。
• 403 ：服务器收到请求，但是拒绝提供服务。
• 404 ：(未找到) 服务器找不到请求的网页。
• 500： (服务器内部错误) 服务器遇到错误，无法完成请求。
• 实际中遇到的
  • 上传视频的时候，Nginx有上传文件大小限制，如果超过Nginx大小，出现413
  • 413：请求体过大
  • 使用Nginx配置客户端大小

解释一下HTTP长连接和短连接？

在 HTTP/1.0 中，默认使用的是 短连接 。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

但从 HTTP/1.1 起，默认使用 长连接 ，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码： Connection:keep-alive

HTTP1.0和HTTP1.1的区别?

• 长连接 ：
  • HTTP1.0默认使用短连接，每次请求都需要建立新的TCP连接，连接不能复用。
  • HTTP1.1支持长连接， 复用TCP连接，允许客户端通过同一连接发送多个请求 。
  • 不过，这个优化策略也存在问题，当一个队头的请求不能收到响应的资源时，它将会阻塞后面的请求。这就是“队头阻塞”问题。
• 断点续传 ：HTTP1.0 不支持断点续传。HTTP1.1 新增了 range 字段，用来指定数据字节位置，支持断点续传。
• 错误通知的管理 ：在HTTP1.1中新增了24个错误状态响应码
• Host头处理 ：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名。到了HTTP1.1时代，虚拟主机技术发展迅速，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址，故HTTP1.1增加了HOST信息。

HTTP1.1和 HTTP2.0的区别？

HTTP2.0相比HTTP1.1支持的特性：

• 新的二进制格式 ：HTTP1.1 基于文本格式传输数据； HTTP2.0采用二进制格式传输数据 ，解析更高效。
• 多路复用 ：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够 并行的传输而不被阻塞 ， 避免 HTTP1.1 出现的”队头堵塞”问题 。
• 头部压缩 ：
  • HTTP1.1的头部（header）带有大量信息，而且每次都要重复发送；
  • HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表， 既避免了重复header的传输，又减小了需要传输的大小 。
• 服务端推送：HTTP2.0允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

HTTPS与HTTP的区别？

• HTTP是 超文本传输协议 ，信息是 明文传输 ；HTTPS则**是具有安全性的ssl加密传输协议。**
• HTTP和HTTPS用的端口不一样，HTTP端口是80，HTTPS是443。
• HTTPS协议需要到CA机构申请证书，一般需要一定的费用。
• HTTP运行在TCP协议之上；HTTPS运行在SSL协议之上，SSL运行在TCP协议之上。

浏览器中输入URL返回页面过程？DNS解析过程？

• 域名解析（域名 www.baidu.com 变为 ip 地址）
  • 浏览器搜索自己的DNS缓存（维护一张域名与IP的对应表）；
  • 若没有，则搜索操作系统的DNS缓存（维护一张域名与IP的对应表）；
  • 若没有，则搜索操作系统的hosts文件（维护一张域名与IP的对应表）。
  • 若都没有，则找 tcp/ip 参数中设置的 首选 dns 服务器 ， 即本地 dns 服务器 （递归查询），本地域名服务器查询自己的dns缓存，如果没有，则进行迭代查询。 将本地dns服务器将IP返回给操作系统，同时缓存IP 。
• 发起 tcp 的三次握手，建立 tcp 连接。
• 建立 tcp 连接后发起 http 请求。
• 服务器响应 http 请求，客户端得到 html 代码。
• 浏览器解析 html 代码，并请求 html 中的资源。
• 浏览器对页面进行渲染，并呈现给用户。

GET请求和POST请求的区别？

使用上的区别

• GET使用URL或Cookie传参，而POST将数据放在BODY中”，这个是因为HTTP协议用法的约定。
• GET方式提交的数据有长度限制，则POST的数据则可以非常大”，这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。
• POST比GET安全，因为数据在地址栏上不可见”，这个说法没毛病，但依然不是GET和POST本身的区别。

本质区别

• GET和POST最大的区别主要是 GET请求是幂等性的 ，POST请求不是。这个是它们本质区别。
• 幂等性是 指一次和多次请求某一个资源应该具有同样的副作用 。简单来说意味着 对同一URL的多个请求应该返回同样的结果 。

什么是 Cookie 和 Session ?

什么是 Cookie

• HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是 服务器发送到用户浏览器并保存在本地的一小块数据
• 它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
• 通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

什么是 Session

• Session 代表着服务器和客户端一次会话的过程。
• Session 对象存储特定用户会话所需的属性及配置信息。
• 这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。
• 当客户端关闭会话，或者 Session 超时失效时会话结束。

Cookie和Session的区别？

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

Cookie 和 Session 是如何配合的呢？

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。

当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

标签：请求,报文,TCP,计算机网络,服务器,连接,客户端
来源： https://blog.csdn.net/qq_36389060/article/details/123116528

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。