HTTP请求的Headers里所包含的部分详解_kxkltey的博客-CSDN博客_header请求头包括哪些
网络协议是计算机在通信过程中要遵循的一些约定好的规则。 网络分层的原因:
- 易于实现和维护,因为各层之间是独立的,层与层之间不会收到影响。
- 有利于标准化的制定
思路: 这道面试题主要考察候选人,是否掌握 HTTP 状态码这个基础知识点。
常见状态码:
- 101: 切换请求协议
- 200:(请求成功)。服务器已成功处理了请求。 通常,这表示服务器提供了请求的网页。
- 301 : (永久移动,永久性重定向,会缓存) 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
- 302:(临时移动,临时重定向,不会缓存) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
- 400 :客户端请求有语法错误,不能被服务器所理解。
- 403 :服务器收到请求,但是拒绝提供服务,服务器禁止访问,权限有关。
- 404 :(未找到) 服务器找不到请求的网页。
- 494:请求头太大
- 495:https证书错误
- 496:https 没有证书
- 497:http到https
- 498:取消
- 499:客户端关闭链接(服务器端处理的时间过长,客户端“不耐烦”了,断开了链接。)
- 代理服务器认为客户端发起的请求过于危险,所以主动切断了
- 代理服务器没有办法连接到其他服务,导致timeout
- 500: (服务器内部错误) 服务器遇到错误,无法完成请求。
- 502: 网关错误
- 504: 网关超时
状态码开头代表类型:
共同点:301和302状态码都表示重定向,就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址,这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)。 不同点:301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了),搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;302表示旧地址A的资源还在(仍然可以访问),这个重定向只是临时地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保存旧的网址。 SEO中302好于301。
补充,重定向原因:
- 网站调整(如改变网页目录结构);
- 网页被移到一个新地址;
- 网页扩展名改变(如应用需要把.php改成.Html或.shtml)。
(1)502是网关错误,504是网关超时
(2)二者很类似,502是代理服务器后面的真实服务器节点配置出了问题或者已经挂掉了,而504是代理服务器后面的真实服务器已经过载,它要处理的请求报文实在太多,忙不过来了。
(3)502还有一种情况就是nginx与fastcgi即PHP进程配合的不恰当,导致返回502网关错误。
思路: 这道题主要考察候选人,是否掌握HTTP 请求方式这个基础知识点,我们用得比较多就是GET 和 POST啦。
方法 | 作用 |
---|---|
GET | 获取资源 |
POST | 传输实体主体,用于发送包含用户提交数据的请求 |
PUT | 上传文件,像服务器提交数据,以 **修改 **数据 |
DELETE | 删除文件,删除服务器上的某些资源 |
HEAD | 和GET方法类似,但只返回报文首部,不返回报文实体主体部分 |
PATCH | 对资源进行部分修改 |
OPTIONS | 查询指定的URL支持的方法,返回所有可用的方法,常用于跨域 |
CONNECT | 要求用ssl隧道协议连接代理 |
TRACE | 服务器会将通信路径返回给客户端,追踪请求-响应的传输路径 |
为了方便记忆,可以将PUT、DELETE、POST、GET理解为客户端对服务端的增删改查。
- PUT:上传文件,向服务器添加数据,可以看作增
- DELETE:删除文件
- POST:传输数据,向服务器提交数据,对服务器数据进行更新。
- GET:获取资源,查询服务器资源
使用上的区别:
- GET使用URL或Cookie传参,而POST将数据放在BODY中”,这个是因为HTTP协议用法的约定。
- GET方式提交的数据有长度限制,则POST的数据则可以非常大”,这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。
- POST比GET安全,因为数据在地址栏上不可见”,这个说法没毛病,但依然不是GET和POST本身的区别。
本质区别
GET和POST最大的区别主要是GET请求是幂等性的,POST请求不是。这个是它们本质区别。
幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。
思路: 这道题主要考察的知识点是 POST 和 GET 的区别,可以从数据包、编码方式、请求参数、收藏为书签、历史记录、安全性等几方面去回答哈。
思路: 这道题主要考察候选人,计算机网络体系结构这个基础知识点。计算机网路体系结构呢,有三层:ISO 七层模型、TCP/IP 四层模型、五层体系结构。大家可以记住这个图,如下
ISO 七层模型是国际标准化组织(International Organization for Standardization)制定的一个用于计算机或通信系统间互联的标准体系。OSI七层模型详解
- 应用层:网络服务与最终用户的一个接口,常见的协议有:HTTP FTP SMTP SNMP DNS.
- 表示层:数据的表示、安全、压缩。,确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
- 会话层:建立、管理、终止会话, 对应主机进程,指本地主机与远程主机正在进行的会话.
- 传输层:定义传输数据的协议端口号,以及流控和差错校验, 协议有TCP UDP.
- 网络层:进行逻辑地址寻址,实现不同网络之间的路径选择, 协议有ICMP IGMP IP 等.
- 数据链路层:在物理层提供比特流服务的基础上,建立相邻结点之间的数据链路。
- 物理层:建立、维护、断开物理连接。
★
- 应用层:对应于 OSI 参考模型的(应用层、表示层、会话层)。
- 传输层: 对应 OSI 的传输层,为应用层实体提供端到端的通信功能,保证了数据包的顺序传送及数据的完整性。
- 网际层:对应于 OSI 参考模型的网络层,主要解决主机到主机的通信问题。
- 网络接口层:与 OSI 参考模型的数据链路层、物理层对应。
★
- 应用层:对应于 OSI 参考模型的(应用层、表示层、会话层)。
- 传输层:对应 OSI 参考模型的的传输层
- 网络层:对应 OSI 参考模型的的网络层
- 数据链路层:对应 OSI 参考模型的的数据链路层
- 物理层:对应 OSI 参考模型的的物理层。
思路: 这道题主要考察候选人,是否理解 Http 协议,它为什么是无状态的呢?如何使它有状态呢?
如何理解无状态这个词呢?
HTTP的无状态,指协议对于事务处理没有记忆能力,不对通信状态进行保存,服务器无法判断用户身份。即打开一个服务器上的网页和上一次打开这个服务器上的网页之间没有任何联系。服务器不会去记住你是谁,所以是无状态协议。
可以通过一个生活中的例子,来更好理解并记住它: 有状态场景:
- 小红:今天吃啥子?
- 小明:罗非鱼~
- 小红:味道怎么样呀?
- 小明:还不错,好香。
无状态的场景:
- 小红:今天吃啥子?
- 小明:罗非鱼~
- 小红:味道怎么样呀?
- 小明:?啊?你说啥?什么鬼?什么味道怎么样?
Http 加了 Cookie 的话:
- 小红:今天吃啥子?
- 小明:罗非鱼~
- 小红:你今天吃的罗非鱼,味道怎么样呀?
- 小明:还不错,好香。
思路: 这道题主要考察的知识点是 HTTP 的请求过程,DNS 解析,TCP 三次握手,四次挥手这几个要点,我们都可以讲下。
- DNS 解析,查找域名对应的 IP 地址。
- 与服务器通过三次握手,建立 TCP 连接
- 向服务器发送 HTTP 请求
- 服务器处理请求,返回网页内容
- 浏览器解析并渲染页面
- TCP 四次挥手,连接结束
在浏览器中输入 www.baidu.com
后,整个过程可以分为以下几个步骤:
- 本地缓存查询:浏览器首先检查本地缓存中是否存在
www.baidu.com
的 DNS 解析结果。 - 操作系统缓存查询:如果本地缓存没有,浏览器会向操作系统查询是否有该域名的缓存记录。
- 路由器缓存查询:如果操作系统没有缓存,查询会发送到路由器,看其缓存中是否有该域名的记录。
- ISP DNS 服务器查询:如果路由器没有缓存,则请求会发送到互联网服务提供商(ISP)的 DNS 服务器。
- 递归查询:如果 ISP 的 DNS 服务器没有缓存,递归地查询根 DNS 服务器、顶级域名(TLD)服务器和权威 DNS 服务器,最终获取
www.baidu.com
对应的 IP 地址。
- 三次握手:通过 TCP 协议与目标服务器建立连接。三次握手过程如下:
- 客户端发送一个 SYN(同步)包到服务器,表示希望建立连接。
- 服务器返回一个 SYN-ACK(同步-确认)包,表示同意连接。
- 客户端发送一个 ACK(确认)包,确认连接建立。
- 构建请求报文:浏览器构建 HTTP 请求报文,包括请求行、请求头和请求体(如果是 POST 请求)。
- 发送请求:浏览器通过建立的 TCP 连接向服务器发送 HTTP 请求报文。
- 请求解析:服务器接收到 HTTP 请求后,解析请求报文,提取请求的资源路径、参数和其他信息。
- 请求处理:服务器根据请求的资源路径和参数进行处理,可能涉及数据库查询、业务逻辑处理等。
- 生成响应:服务器处理完请求后,生成 HTTP 响应报文,包括状态行、响应头和响应体。
- 发送响应报文:服务器通过 TCP 连接将生成的 HTTP 响应报文发送给浏览器。
- 四次挥手:当数据传输完成后,客户端和服务器通过四次挥手过程关闭 TCP 连接。
- 客户端发送一个 FIN(终止)包,表示完成数据发送。
- 服务器返回一个 ACK(确认)包,表示接收到 FIN 包。
- 服务器发送一个 FIN 包,表示完成数据发送。
- 客户端返回一个 ACK 包,确认连接关闭。
- 解析响应报文:浏览器接收到 HTTP 响应后,解析响应报文,提取状态码、响应头和响应体。
- 处理状态码:根据状态码决定下一步操作(例如,301/302 重定向、200 成功等)。
- 解析 HTML:如果响应体是 HTML 文档,浏览器解析 HTML,构建 DOM 树。
- 解析 CSS:解析 HTML 时遇到 CSS 文件,浏览器发送请求加载 CSS 文件,构建 CSSOM 树。
- 解析 JavaScript:解析 HTML 时遇到 JavaScript 文件,浏览器发送请求加载 JavaScript 文件,并执行脚本。
- 渲染页面:构建 DOM 树和 CSSOM 树后,浏览器生成渲染树,并计算布局、绘制页面。
- 事件处理:页面加载完成后,浏览器开始处理用户交互事件(如点击、输入等),执行相应的 JavaScript 代码。
- DNS 解析:将域名
www.baidu.com
解析为 IP 地址。 - TCP 连接:通过三次握手建立 TCP 连接。
- HTTP 请求:发送 HTTP 请求到服务器。
- 服务器处理:服务器处理请求并生成响应。
- HTTP 响应:服务器发送 HTTP 响应到浏览器。
- 解析响应:浏览器解析响应内容。
- 加载资源:加载页面中的各种资源(CSS、JavaScript、图片等)。
- 渲染页面:浏览器渲染页面并处理用户交互。
- 本地服务器
- 存储在网站的服务器上:资源文件直接存储在网站的服务器上,并通过绝对或相对路径引用。
例如,图片存储在
images
文件夹中,可以通过<img src="/images/picture.jpg">
引用。 - CDN(内容分发网络):为了提升加载速度和分担服务器压力,资源文件可以存储在 CDN 上。CDN 将资源分布在多个地理位置的服务器上,用户可以从最近的服务器加载资源。
- 存储在网站的服务器上:资源文件直接存储在网站的服务器上,并通过绝对或相对路径引用。
例如,图片存储在
- 外部资源
- 第三方服务:使用外部服务提供的资源链接。例如,嵌入 YouTube 视频可以通过 标签引用 YouTube 的链接。
- 云存储:图片和视频可以存储在云存储服务(如 AWS S3、Google Cloud Storage)上,并通过公共链接访问。
- **动态生成 **
- 服务器动态生成:一些图片或视频可能是由服务器动态生成的,例如用户上传的内容、图表生成等。
- 客户端生成:利用 JavaScript 在客户端生成的资源,例如使用 Canvas API 绘制的图形。
思路: 这道题主要考察的知识点是 HTTP 几个版本的区别,我们记住HTTP/1.0默认是短连接,可以强制开启,HTTP/1.1 默认长连接,HTTP/2.0 采用多路复用就差不多啦。
HTTP/1.0
- 默认使用短连接,每次请求都需要建立 TCP 连接。服务完成立即断开,开销大;
- 错误状态响应码少;
- 不支持断点续传。它可以设置
Connection: keep-alive
这个字段,强制开启长连接。
HTTP/1.1
- 默认长连接,即 TCP 连接默认不关闭,可以被多个请求复用。
- 分块传输编码,即服务端每产生一块数据,就发送一块,用” 流模式” 取代” 缓存模式”。
- 管道机制,即在同一个 TCP 连接里面,客户端可以同时发送多个请求。
HTTP/2.0
- 二进制协议,1.1 版本的头信息是文本(ASCII 编码),数据体可以是文本或者二进制;2.0 中,头信息和数据体都是二进制,实现方便,健壮性更好。
- 完全多路复用,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应。
- 报头压缩:HTTP 协议不带有状态,每次请求都必须附上所有信息。Http/2.0 引入了头信息压缩机制,使用 gzip 或 compress 压缩后再发送,同时通信的双方各自缓存一份header fields表,避免了header的重复传输。
- 服务端推送:允许服务器未经请求,主动向客户端发送资源。
HTTP协议的长连接和短连接,实质上就是TCP协议的长连接和短连接。 HTTP/1.0默认使用短连接,即Client和Server每进行一次HTTP操作,就建立一次连接,任务结束就中断。 HTTP/1.1起默认使用长连接,网页打开后,Client和Server间传输数据的TCP连接不会关闭,之后再进行访问就直接用已建立的连接。
在HTTP/1.0中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源,如JavaScript文件、图像文件、CSS文件等;当浏览器每遇到这样一个Web资源,就会建立一个HTTP会话。
短连接的优缺点:
管理起来比较简单,存在的连接都是有用的连接,不需要额外的控制手段。
但从 HTTP/1.1起,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头有加入这行代码:Connection:keep-alive
使用场景: 通常浏览器访问服务器的时候就是短连接。 对于服务端来说,长连接会耗费服务端的资源,而且用户用浏览器访问服务端相对而言不是很频繁的 如果有几十万,上百万的连接,服务端的压力会非常大,甚至会崩溃。 所以对于并发量大,请求频率低的,建议使用短连接。
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接要客户端和服务端都支持长连接。
长连接的生命周期 正常情况下,一条TCP长连接建立后,只要双不提出关闭请求并且不出现异常情况,这条连接是一直存在的. 操作系统不会自动去关闭它,甚至经过物理网络拓扑的改变之后仍然可以使用。 所以一条连接保持几天、几个月、几年或者更长时间都有可能,只要不出现异常情况或由用户(应用层)主动关闭。 客户端和服务单可一直使用该连接进行数据通信。 长连接的优点:
- 长连接可以省去较多的TCP建立和关闭的操作,减少网络阻塞的影响,
- 当发生错误时,可以在不关闭连接的情况下进行提示,
- 减少CPU及内存的使用,因为不需要经常的建立及关闭连接。
长连接的缺点:
- 连接数过多时,影响服务端的性能和并发数量。
使用场景
- 数据库的连接就是采用TCP长连接.
- RPC,远程服务调用,在服务器,一个服务进程频繁调用另一个服务进程,可使用长连接,减少连接花费的时间。
总结 1.对于长连接和短连接的使用是需要根据应用场景来判断的 2.长连接并不是万能的,也是需要维护的,
HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。
应用层协议大多都有HeartBeat机制,通常是客户端每隔一小段时间向服务器发送一个数据包,通知服务器自己仍然在线。 并传输一些可能必要的数据。使用心跳包的典型协议是IM,比如QQ/MSN/飞信等协议。 在TCP的机制里面,本身是存在有心跳包的机制的,也就是TCP的选项:SO_KEEPALIVE。 系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。 而且逻辑层处理断线可能也不是那么好处理。一般,如果只是用于保活还是可以的。
因为网络的不可靠性, 有可能在 TCP 保持长连接的过程中, 由于某些突发情况, 例如网线被拔出, 突然掉电等, 会造成服务器和客户端的连接中断. 在这些突发情况下, 如果恰好服务器和客户端之间没有交互的话, 那么它们是不能在短时间内发现对方已经掉线的. 心跳机制即可解决此类问题。使用心跳来判断client是否还连接到server上。
默认KeepAlive状态是不打开的。 需要将setsockopt将SOL_SOCKET.SO_KEEPALIVE设置为1才是打开KeepAlive状态, 并且可以设置三个参数: tcp_keepalive_time ,tcp_keepalive_probes , tcp_keepalive_intvl, 分别表示:连接闲置多久开始发keepalive的ack包、发几个ack包不回复才当对方已断线、两个ack包之间的间隔。 很多网络设备,尤其是NAT路由器,由于其硬件的限制(例如内存、CPU处理能力),无法保持其上的所有连接,因此在必要的时候,会在连接池中选择一些不活跃的连接踢掉。 典型做法是LRU,把最久没有数据的连接给T掉。 通过使用TCP的KeepAlive机制(修改那个time参数),可以让连接每隔一小段时间就产生一些ack包,以降低被踢掉的风险,当然,这样的代价是额外的网络和CPU负担。
两种方式实现心跳机制:
-
使用 TCP 协议层面的 keepalive 机制.
-
在应用层上实现自定义的心跳机制.
虽然在 TCP 协议层面上, 提供了 keepalive 保活机制, 但是使用它有几个缺点:
-
它不是 TCP 的标准协议, 并且是默认关闭的.
-
TCP keepalive 机制依赖于操作系统的实现, 默认的 keepalive 心跳时间是 两个小时, 并且对 keepalive 的修改需要系统调用(或者修改系统配置), 灵活性不够.
-
TCP keepalive 与 TCP 协议绑定, 因此如果需要更换为 UDP 协议时, keepalive 机制就失效了.
使用 TCP 层面的 keepalive 机制比自定义的应用层心跳机制节省流量,
默认KeepAlive状态是不打开的。 需要将setsockopt将SOL_SOCKET.SO_KEEPALIVE设置为1才是打开KeepAlive状态, 并且可以设置三个参数: tcp_keepalive_time ,tcp_keepalive_probes , tcp_keepalive_intvl, 分别表示:连接闲置多久开始发keepalive的ack包、发几个ack包不回复才当对方已断线、两个ack包之间的间隔。 很多网络设备,尤其是NAT路由器,由于其硬件的限制(例如内存、CPU处理能力),无法保持其上的所有连接,因此在必要的时候,会在连接池中选择一些不活跃的连接踢掉。 典型做法是LRU,把最久没有数据的连接给T掉。 通过使用TCP的KeepAlive机制(修改那个time参数),可以让连接每隔一小段时间就产生一些ack包,以降低被踢掉的风险,当然,这样的代价是额外的网络和CPU负担。
两种方式实现心跳机制:
-
使用 TCP 协议层面的 keepalive 机制.
-
在应用层上实现自定义的心跳机制.
虽然在 TCP 协议层面上, 提供了 keepalive 保活机制, 但是使用它有几个缺点:
-
它不是 TCP 的标准协议, 并且是默认关闭的.
-
TCP keepalive 机制依赖于操作系统的实现, 默认的 keepalive 心跳时间是 两个小时, 并且对 keepalive 的修改需要系统调用(或者修改系统配置), 灵活性不够.
-
TCP keepalive 与 TCP 协议绑定, 因此如果需要更换为 UDP 协议时, keepalive 机制就失效了.
使用 TCP 层面的 keepalive 机制比自定义的应用层心跳机制节省流量,
这个问题记住keep-alive
就好,也就是说,在 HTTP 中响应体的Connection字段指定为keep-alive
即可
思路: 这道题实际上是考察 TCP 长连接的知识点,HTTP 的长连接实质是指 TCP 的长连接。至于什么时候超时,我们记住这几个参数如tcp_keepalive_time、tcp_keepalive_probes就好啦
什么是 HTTP 的长连接?
- HTTP 分为长连接和短连接,本质上说的是 TCP 的长短连接。TCP 连接是一个双向的通道,它是可以保持一段时间不关闭的,因此 TCP 连接才具有真正的长连接和短连接这一说法哈。
- TCP 长连接可以复用一个 TCP 连接,来发起多次的 HTTP 请求,这样就可以减少资源消耗,比如一次请求 HTML,如果是短连接的话,可能还需要请求后续的 JS/CSS。
如何设置长连接?
通过在头部(请求和响应头)设置Connection字段指定为keep-alive
,HTTP/1.0 协议支持,但是是默认关闭的,从 HTTP/1.1 以后,连接默认都是长连接。
在什么时候会超时呢?
- HTTP 一般会有 httpd 守护进程,里面可以设置keep-alive timeout,当 tcp 连接闲置超过这个时间就会关闭,也可以在 HTTP 的 header 里面设置超时时间
- TCP 的keep-alive包含三个参数,支持在系统内核的 net.ipv4 里面设置;当 TCP 连接之后,闲置了tcp_keepalive_time,则会发生侦测包,如果没有收到对方的 ACK,那么会每隔 tcp_keepalive_intvl 再发一次,直到发送了tcp_keepalive_probes,就会丢弃该连接。
1. tcp_keepalive_intvl = 15 2. tcp_keepalive_probes = 5 3. tcp_keepalive_time = 1800
思路: 这道题实际上考察的知识点是 HTTP 与 HTTPS 的区别,这个知识点非常重要,可以从安全性、数据是否加密、默认端口等这几个方面去回答哈。其实,当你理解 HTTPS 的整个流程,就可以很好回答这个问题啦。
我的答案如下: HTTP,即超文本传输协议,是一个基于 TCP/IP 通信协议来传递明文数据的协议。HTTP 会存在这几个问题:
- 请求信息是明文传输,容易被窃听截取。
- 没有验证对方身份,存在被冒充的风险
- 数据的完整性未校验,容易被中间人篡改
为了解决 Http 存在的问题,Https 出现啦。 Https 是什么?
HTTPS= HTTP+SSL/TLS,可以理解 Https 是身披 SSL(Secure Socket Layer,安全套接层) 的 HTTP。
思路: HTTP 请求,一个非常非常基础的知识点,一定需要掌握的。其实觉得跟浏览器地址栏输入 url 到显示主页这道题有点类似。
我的答案如下:
HTTP 是一个基于 TCP/IP 协议来传递数据的超文本传输协议,传输的数据类型有 HTML, 图片等。以访问百度有例子,看下一次 Http 的请求过程吧
Http 请求过程
- 客户端进行 DNS 域名解析,得到对应的 IP 地址
- 根据这个 IP,找到对应的服务器建立连接(三次握手)
- 建立 TCP 连接后发起 HTTP 请求(一个完整的 http 请求报文)
- 服务器响应 HTTP 请求,客户端得到 html 代码
- 客户端解析 html 代码,用 html 代码中的资源 (如 js,css, 图片等等) 渲染页面。
- 服务器关闭 TCP 连接(四次挥手)
思路: 这道题实际上考察的知识点是 HTTPS 的工作流程,大家需要回答这几个要点,公私钥、数字证书、加密、对称加密、非对称加密。
- HTTPS = HTTP + SSL/TLS,也就是用 SSL/TLS 对数据进行加密和解密,Http 进行传输。
- SSL,即 Secure Sockets Layer(安全套接层协议),是网络通信提供安全及数据完整性的一种安全协议。
- TLS,即 Transport Layer Security(安全传输层协议),它是 SSL3.0 的后续版本。
- 客户端发起 Https 请求,连接到服务器的 443 端口。
- 服务器必须要有一套数字证书(证书内容有公钥、证书颁发机构、失效日期等)。
- 服务器将自己的数字证书发送给客户端(公钥在证书里面,私钥由服务器持有)。
- 客户端收到数字证书之后,会验证证书的合法性。如果证书验证通过,就会生成一个随机的对称密钥,用证书的公钥加密。
- 客户端将公钥加密后的密钥发送到服务器。
- 服务器接收到客户端发来的密文密钥之后,用自己之前保留的私钥对其进行非对称解密,解密之后就得到客户端的密钥,然后用客户端密钥对返回数据进行对称加密,酱紫传输的数据都是密文啦。
- 服务器将加密后的密文返回到客户端。
- 客户端收到后,用自己的密钥对其进行对称解密,得到服务器返回的数据。
作用是建立安全连接,能和多个应用层协议协和使用保证安全传输。
- 记录协议:接收消息并处理,然后将处理过的消息继续传递。包括加解密、解压缩、分段重组等。
- 握手协议:建立在三次握手之后,为建立安全连接提供参数并进行双方的真实性认证。
- 警告协议:规定可能出现的错误等级和应对方式。
- 密码规范改变协议:在握手结束前发送,通知对方在之后的消息中使用商量好的加密算法。
粗略地分: 1xx:临时响应/请求正在处理; 2xx:成功 3xx:重定向 4xx:请求错误 5xx:服务器错误。 常见的状态码有: 200:成功。 302:临时重定向到指定网页。 304:not modified服务器允许访问资源,但请求未满足条件。 400:bad request,请求报文存在语法错误。 401:unauthorized未授权,要求身份验证。 403:forbidden禁止,服务器拒绝访问。 404:not found未找到,服务器找不到请求的网页。 405:方法禁用,Post当成Get。 502:服务器网关错误。 503:service unavailable,服务器超负荷或停机维护。 504:网关超时,nginx请求超时。
302 和 301 都有重定向的含义,区别:
- 301:(永久性转移)请求的网页已被永久移动到新位置。服务器返回此响应时,会自动将请求者转到新位置。
- 302:(暂时性转移)服务器目前正从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似,会自动将请求者转到不同的位置。
网上有个很形象的例子比喻:
当一个网站或者网页 24—48 小时内临时移动到一个新的位置,这时候就要进行 302 跳转,打个比方说,我有一套房子,但是最近走亲戚去亲戚家住了,过两天我还回来的。而使用 301 跳转的场景就是之前的网站因为某种原因需要移除掉,然后要到新的地址访问,是永久性的,就比如你的那套房子其实是租的,现在租期到了,你又在另一个地方找到了房子,之前租的房子不住了。
思路: 这道题考查的知识点,不仅仅是数字签名,数字证书,很可能面试官也会问你 https 的原理的,因为 https 原理跟数字证书有关的哈,大家需要掌握 https 原理哦。
数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证,人们可以在网上用它来识别对方的身份。它的出现,是为了避免身份被篡改冒充的。比如 Https 的数字证书,就是为了避免公钥被中间人冒充篡改:
数字证书构成
- 公钥和个人等信息,经过 Hash 摘要算法加密,形成消息摘要;将消息摘要拿到拥有公信力的认证中心(CA),用它的私钥对消息摘要加密,形成数字签名。
- 公钥和个人信息、数字签名共同构成数字证书。
思路: 这道题考察的知识点是对称加密与非对称加密算法,什么是对称加密,什么是非对称加密呢?
对称加密:指加密和解密使用同一密钥,优点是运算速度较快,缺点是如何安全将密钥传输给另一方。常见的对称加密算法有:DES、AES 等。
对称加密
非对称加密:指的是加密和解密使用不同的密钥(即公钥和私钥)。公钥与私钥是成对存在的,如果用公钥对数据进行加密,只有对应的私钥才能解密。常见的非对称加密算法有 RSA。
思路: 这道题考察的知识点是DNS 域名解析,http 请求的过程,是涉及到 DNS 域名解析的,这道面试题也挺经典的,大家可以看下《图解 HTTP》那本书哈。
DNS,英文全称是domain name system,域名解析系统,是 Internet 上作为域名和 IP 相互映射的一个分布式数据库。它的作用很明确,就是可以根据域名查出对应的 IP 地址。在浏览器缓存、本地 DNS 服务器、根域名服务器都是怎么查找的,大家回答的时候都可以说下哈。
DNS 解析查找过程 假设你要查询**www.baidu.com**的 IP 地址:
- 首先会查找浏览器的缓存, 看看是否能找到**www.baidu.com**对应的 IP 地址,找到就直接返回;否则进行下一步。
- 将请求发往给本地 DNS 服务器,如果查找到也直接返回,否则继续进行下一步;
- 本地 DNS 服务器向根域名服务器发送请求,根域名服务器返回负责
.com
的顶级域名服务器的 IP 地址的列表。- 本地 DNS 服务器再向其中一个负责
.com
的顶级域名服务器发送一个请求,返回负责.baidu
的权威域名服务器的 IP 地址列表。- 本地 DNS 服务器再向其中一个权威域名服务器发送一个请求,返回**www.baidu.com**所对应的 IP 地址。
思路: 这道题考察的知识点是CSRF 攻击,它是属于网络安全这块的知识点,还有Xss 攻击、SQL 注入、DDoS等这些常见的网络攻击,我们都需要知道攻击的流程哈。
什么是 CSRF 攻击?
★ CSRF,跨站请求伪造(英文全称是 Cross-site request forgery),是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。
CSRF 是如何攻击的呢?
来看一个来自百度百科的例子哈:
- Tom 登陆银行,没有退出,浏览器包含了 Tom 在银行的身份认证信息。
- 黑客 Jerry 将伪造的转账请求,包含在在帖子
- Tom 在银行网站保持登陆的情况下,浏览帖子
- 将伪造的转账请求连同身份认证信息,发送到银行网站
- 银行网站看到身份认证信息,以为就是 Tom 的合法操作,最后造成 Tom 资金损失。
怎么解决 CSRF 攻击呢?
- 检查 Referer 字段。
- 添加校验 token。
为了大家方便记忆,画了个思维导图,如下:
思路: 这是一个比较基础的知识点,经常有小伙伴会搞混。
- Socket 其实就是等于IP 地址 + 端口 + 协议。
★ 具体来说,Socket 是一套标准,它完成了对 TCP/IP 的高度封装,屏蔽网络细节,以方便开发者更好地进行网络编程。
- WebSocket 是一个持久化的协议,它是伴随 H5 而出的协议,用来解决http 不支持持久化连接的问题。
- Socket 一个是网编编程的标准接口,而 WebSocket 则是应用层通信协议。
DoS 攻击是一种试图使目标计算机资源无法正常运行或提供服务的攻击方式。攻击者通过向目标系统发送大量请求,耗尽系统资源(如 CPU、内存、带宽),从而导致服务中断或显著下降。这种攻击通常通过单个设备或单个互联网连接进行。 特点:
- 来源单一
- 目标是耗尽资源
- 容易检测,防护相对简单
示例:
- 发送大量虚假请求使服务器超载
- 利用漏洞触发系统崩溃
DDoS 攻击是分布式拒绝服务攻击,攻击者通过控制大量受感染的设备(如僵尸网络),同时向目标系统发送大量请求,使得目标系统无法处理正常的流量,从而导致服务中断。DDoS 攻击的来源是分布式的,通常遍布全球。 特点:
- 来源分布广泛
- 攻击规模巨大
- 难以防范和追踪
示例:
- 利用僵尸网络向目标网站发送海量请求
- 分布式地向目标系统发送大量垃圾数据
DRDoS 攻击是一种反射型的分布式拒绝服务攻击,攻击者利用第三方服务器作为反射器,向目标系统发送伪造的请求包,使这些第三方服务器将响应包发送给目标系统,从而达到攻击的目的。攻击者通过伪造源地址为目标系统的 IP 地址,使反射器的响应包都指向目标系统,导致目标系统资源耗尽。 特点:
- 利用第三方服务器进行反射
- 源地址伪造,难以追踪攻击者
- 攻击放大效果明显
示例:
- 利用 NTP 服务器的 monlist 命令进行反射攻击
- 利用 DNS 服务器的解析请求进行放大攻击
区别:
- DoS:单一来源,攻击规模小,防护相对简单
- DDoS:多来源,攻击规模大,防护难度高
- DRDoS:利用反射放大,攻击规模更大,追踪难度高
防护措施:
- DoS 防护:
- 设置合理的限流和连接超时
- 监控和过滤异常流量
- DDoS 防护:
- 使用防火墙和入侵检测系统(IDS)
- 部署 DDoS 防护服务,如 Cloudflare、Akamai
- 配置 CDN 缓解流量
- DRDoS 防护:
- 配置反射服务器,限制响应请求
- 禁用不必要的服务和功能,如 NTP monlist、DNS 递归解析
- 使用流量分析工具识别和阻断伪造流量
通过理解和部署这些防护措施,可以有效应对各种类型的拒绝服务攻击,保障系统的稳定性和安全性。
思路: XSS 攻击也是比较常见,XSS,叫跨站脚本攻击(Cross-Site Scripting),因为会与层叠样式表 (Cascading Style Sheets, CSS) 的缩写混淆,因此有人将跨站脚本攻击缩写为 XSS。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码,当用户浏览该页之时,嵌入其中 Web 里面的 html 代码会被执行,从而达到恶意攻击用户的特殊目的。XSS 攻击一般分三种类型:存储型 、反射型 、DOM 型 XSS
拿反射型举个例子吧,流程图如下:
- 对输入进行过滤,过滤标签等,只允许合法值。
- HTML 转义
- 对于链接跳转,如
<a href="xxx"
等,要校验内容,禁止以 script 开头的非法链接。 - 限制输入长度
思路: 这道题有点偏 Java web 方向的。以前记得刚出来实习找工作的时候,面试官可喜欢问这道题啦,当时我记的答案就是,forward 是转发,redirect 是重定向。
我的答案如下:
★
- 直接转发方式(Forward) ,客户端和浏览器只发出一次请求,Servlet、HTML、JSP 或其它信息资源,由第二个信息资源响应该请求,在请求对象 request 中,保存的对象对于每个信息资源是共享的。
- 间接转发方式(Redirect) 实际是两次 HTTP 请求,服务器端在响应第一次请求的时候,让浏览器再向另外一个 URL 发出请求,从而达到转发的目的。
举个通俗的例子:
★
- 直接转发就相当于:“A 找 B 借钱,B 说没有,B 去找 C 借,借到借不到都会把消息传递给 A”;
- 间接转发就相当于:"A 找 B 借钱,B 说没有,让 A 去找 C 借"。**
看下这两个图,可以更容易理解一些:
- Redirect 的工作原理:
- forward 的工作原理
思路: SQL 注入是最经典的安全问题。无论你是前端开发还是后端开发,都必须掌握的。
★ SQL 注入是一种代码注入技术,一般被应用于攻击 web 应用程序。它通过在 web 应用接口传入一些特殊参数字符,来欺骗应用服务器,执行恶意的 SQL 命令,以达到非法获取系统信息的目的。它目前是黑客对数据库进行攻击的最常用手段之一。
举个常见的业务场景:在 web 表单搜索框输入员工名字,然后后台查询出对应名字的员工。
这种场景下,一般都是前端页面, 把一个名字参数 name 传到后台,然后后台通过 SQL 把结果查询出来
name = "田螺"; // 前端传过来的
// 根据前端传过来的 name 参数,查询数据库员工表 staff
SQL= "select * from staff where name=" + name;
因为 SQL 是直接拼接的,如果我们完全信任前端传的参数的话。假如前端传这么一个参数时''or'1'='1'
,SQL 就变成酱紫的啦。
select * from staff where name=''or'1'='1';
这个 SQL 会把所有的员工信息全都查出来了,酱紫就请求用户已经越权啦。请求者可以获取所有员工的信息,信息已经暴露了啦。
1). 使用 #{} 而不是 ${}
在 MyBatis 中, 使用**#{}**
而不是**${}**
,可以很大程度防止 sql 注入。
- 因为
**#{}**
是一个参数占位符,对于字符串类型,会自动加上 "",其他类型不加。由于 Mybatis 采用预编译,其后的参数不会再进行 SQL 编译,所以一定程度上防止 SQL 注入。 **${}**
是一个简单的字符串替换,字符串是什么,就会解析成什么,存在 SQL 注入风险
2). 不要暴露一些不必要的日志或者安全信息,比如避免直接响应一些 sql 异常信息。
如果 SQL 发生异常了,不要把这些信息暴露响应给用户,可以自定义异常进行响应
3). 不相信任何外部输入参数,过滤参数中含有的一些数据库关键词关键词
可以加个参数校验过滤的方法,过滤union,or
等数据库关键词
4). 适当的权限控制
在你查询信息时,先校验下当前用户是否有这个权限。比如说,实现代码的时候,可以让用户多传一个企业 Id 什么的,或者获取当前用户的 session 信息等,在查询前,先校验一下当前用户是否是这个企业下的等等,是的话才有这个查询员工的权限。
我们先来看 Session 和 Cookie 的概念吧:
- Cookie 是保存在客户端的一小块文本串的数据。客户端向服务器发起请求时,服务端会向客户端发送一个 Cookie,客户端就把 Cookie 保存起来。在客户端下次向同一服务器再发起请求时,Cookie 被携带发送到服务器。服务器就是根据这个 Cookie 来确认身份的。
- session 指的就是服务器和客户端一次会话的过程。Session 利用 Cookie 进行信息处理的,当用户首先进行了请求后,服务端就在用户浏览器上创建了一个 Cookie,当这个 Session 结束时,其实就是意味着这个 Cookie 就过期了。Session 对象存储着特定用户会话所需的属性及配置信息。
Session 和 Cookie 的区别主要有这些:
来看个图吧:
- 用户第一次请求服务器时,服务器根据用户提交的信息,创建对应的 Session,请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器,浏览器接收到服务器返回的 SessionID 信息后,会将此信息存入 Cookie 中,同时 Cookie 记录此 SessionID 是属于哪个域名。
- 当用户第二次访问服务器时,请求会自动判断此域名下是否存在 Cookie 信息,如果存在,则自动将 Cookie 信息也发送给服务端,服务端会从 Cookie 中获取 SessionID,再根据 SessionID 查找对应的 Session 信息,如果没有找到,说明用户没有登录或者登录失效,如果找到 Session 证明用户已经登录可执行后面操作。
- Cookie和Session保存会话状态,用Session来唯一标识用户,用Cookie当作用户通行证。
流程:
- 服务端收到请求处理后生成一个SessionId,将SessionId存入Cookie返回给客户端,将Session内容存储在服务器上。
- 下一次请求时,客户端带着Cookie来请求服务器,服务端从Cookie中取出SessionId,从而实现用户会话状态的保持。
- 第一次登陆后,服务端生成Token给客户端,客户端之后带着Token请求数据即可。减轻服务器的压力,减少频繁查询数据库。
- Cookie:在客户端保存用户信息,安全性较差,并且浏览器会限制cookie数量。例如: 保存登录用户信息,下次自动填写登录信息;登录网 站后访问其他页面就不用登录。
- Session:在服务端记录用户状态,安全性较高,但占用服务器性能。例如:购物车添加物品,根据Session知道用户的购物车。
- Token:在客户端保存认证授权状态,适合前后端分离的项目(处于不同服务器)。
一般可以这么认为,IP 地址 = 网络号 + 主机号。
- 网络号:它标志主机所连接的网络地址表示属于互联网的哪一个网络。
- 主机号:它标志主机地址表示其属于该网络中的哪一台主机。
IP 地址分为 A,B,C,D,E 五大类:
- A 类地址 (1~126):以 0 开头,网络号占前 8 位,主机号占后面 24 位。
- B 类地址 (128~191):以 10 开头,网络号占前 16 位,主机号占后面 16 位。
- C 类地址 (192~223):以 110 开头,网络号占前 24 位,主机号占后面 8 位。
- D 类地址 (224~239):以 1110 开头,保留位多播地址。
- E 类地址 (240~255):以 11110 开头,保留位为将来使用
ARP 协议协议,Address Resolution Protocol,地址解析协议,它是用于实现 IP 地址到 MAC 地址的映射。
- 首先,每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表,以表示 IP 地址和 MAC 地址的对应关系。
- 当源主机需要将一个数据包要发送到目的主机时,会首先检查自己的 ARP 列表,是否存在该 IP 地址对应的 MAC 地址;如果有﹐就直接将数据包发送到这个 MAC 地址;如果没有,就向本地网段发起一个 ARP 请求的广播包,查询此目的主机对应的 MAC 地址。此 ARP 请求的数据包里,包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。
- 网络中所有的主机收到这个 ARP 请求后,会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同,就会忽略此数据包;如果相同,该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中,如果 ARP 表中已经存在该 IP 的信息,则将其覆盖,然后给源主机发送一个 ARP 响应数据包,告诉对方自己是它需要查找的 MAC 地址。
- 源主机收到这个 ARP 响应数据包后,将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中,并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包,表示 ARP 查询失败。
- 简而言之,标识网络中的一台计算机,比较常用的就是IP 地址和 MAC 地址,但计算机的 IP 地址可由用户自行更改,管理起来就相对困难,而 MAC 地址不可更改,所以一般会把 IP 地址和 MAC 地址组合起来使用。
- 那只使用 MAC 地址不用 IP 地址行不行呢?不行的!因为最早就是 MAC 地址先出现的,并且当时并不用 IP 地址,只用 MAC 地址,后来随着网络中的设备越来越多,整个路由过程越来越复杂,便出现了子网的概念。对于目的地址在其他子网的数据包,路由只需要将数据包送到那个子网即可。
- 那为什么要用 IP 地址呢?是因为 IP 地址是和地域相关的,对于同一个子网上的设备,IP 地址的前缀都是一样的,这样路由器通过 IP 地址的前缀就知道设备在在哪个子网上了,而只用 MAC 地址的话,路由器则需要记住每个 MAC 地址在哪个子网,这需要路由器有极大的存储空间,是无法实现的。
- IP 地址可以比作为地址,MAC 地址为收件人,在一次通信过程中,两者是缺一不可的。
基于 TCP 的应用层协议有:HTTP、FTP、SMTP、TELNET、SSH
- HTTP:HyperText Transfer Protocol(超文本传输协议),默认端口 80
- FTP: File Transfer Protocol (文件传输协议), 默认端口 (20 用于传输数据,21 用于传输控制信息)
- SMTP: Simple Mail Transfer Protocol (简单邮件传输协议) , 默认端口 25
- TELNET: Teletype over the Network (网络电传), 默认端口 23
- SSH:Secure Shell(安全外壳协议),默认端口 22
基于 UDP 的应用层协议:DNS、TFTP、SNMP
- DNS : Domain Name Service (域名服务), 默认端口 53
- TFTP: Trivial File Transfer Protocol (简单文件传输协议),默认端口 69
- SNMP:Simple Network Management Protocol(简单网络管理协议),通过 UDP 端口 161 接收,只有 Trap 信息采用 UDP 端口 162。
除时间等待计时器外,TCP 还一个保活计时器(keepalive timer)。设想这样的场景:客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然,服务器以后就不能再收到客户端发来的数据。因此,应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常是两个小时。若两个小时都没有收到客户端的数据,服务端就发送一个探测报文段,以后则每隔 75 秒钟发送一次。若连续发送 10 个探测报文段后仍然无客户端的响应,服务端就认为客户端出了故障,接着就关闭这个连接。
我们先来复习下 TCP 的四次挥手
- 服务器端收到客户端发送的
FIN
后,TCP 协议栈就会自动发送 ACK,接着进入CLOSE_WAIT状态。 - 但是如果服务器端不执行 socket 的 close() 操作,那么就没法进入 LAST_ACK, 导致大量连接处于 CLOSE_WAIT 状态
- 所以,如果服务器出现了大量CLOSE_WAIT状态,一般是程序 Bug,或者关闭 socket 不及时。
- URI,全称是 Uniform Resource Identifier),中文翻译是统一资源标志符,主要作用是唯一标识一个资源。
- URL,全称是 Uniform Resource Location),中文翻译是统一资源定位符,主要作用是提供资源的路径。打个经典比喻吧,URI 像是身份证,可以唯一标识一个人,而 URL 更像一个住址,可以通过 URL 找到这个人。
ICMP,Internet Control Message Protocol ,Internet 控制消息协议。
- ICMP 协议是一种面向无连接的协议,用于传输出错报告控制信息。
- 它是一个非常重要的协议,它对于网络安全具有极其重要的意义。它属于网络层协议,主要用于在主机与路由器之间传递控制信息,包括报告错误、交换受限控制和状态信息等。
- 当遇到 IP 数据无法访问目标、IP 路由器无法按当前的传输速率转发数据包等情况时,会自动发送 ICMP 消息。
比如我们日常使用得比较多的ping,就是基于 ICMP 的。
ping,Packet Internet Groper,是一种因特网包探索器,用于测试网络连接量的程序。Ping 是工作在 TCP/IP 网络体系结构中应用层的一个服务命令, 主要是向特定的目的主机发送 ICMP(Internet Control Message Protocol 因特网报文控制协议) 请求报文,测试目的站是否可达及了解其有关状态
一般来说,ping 可以用来检测网络通不通。它是基于ICMP
协议工作的。假设机器 A ping机器 B,工作过程如下:
- ping 通知系统,新建一个固定格式的 ICMP 请求数据包
- ICMP 协议,将该数据包和目标机器 B 的 IP 地址打包,一起转交给 IP 协议层
- IP 层协议将本机 IP 地址为源地址,机器 B 的 IP 地址为目标地址,加上一些其他的控制信息,构建一个 IP 数据包
- 先获取目标机器 B 的 MAC 地址。
- 数据链路层构建一个数据帧,目的地址是 IP 层传过来的MAC 地址,源地址是本机的MAC 地址
- 机器 B 收到后,对比目标地址,和自己本机的 MAC 地址是否一致,符合就处理返回,不符合就丢弃。
- 根据目的主机返回的 ICMP 回送回答报文中的时间戳,从而计算出往返时间
- 最终显示结果有这几项:发送到目的主机的 IP 地址、发送 & 收到 & 丢失的分组数、往返时间的最小、最大 & 平均值
总结:ping的工作过程
- 向目的主机发送多个ICMP回送请求报文
- 根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。
思路: TCP 连接的三次握手机制,最重要的知识点,必须得会,通讯过程以及客户端、服务器的对应的状态都需要记住哈。
TCp 提供可靠的连接服务,连接是通过三次握手进行初始化的。三次握手的目的就是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。我们一起来看下流程图哈:
- 第一次握手 (发送连接请求报文SYN=1, 初始序号随机seq=x,ACK=0),发送完毕后,客户端就进入 SYN_SENT 状态
- 第二次握手 (发送连接确认报文SYN=1, ACK=1, seq=y, ACKnum=x+1), 发送完毕后,服务器端就进入 SYN_RCV 状态。
- 第三次握手 (发出连接确认报文ACK=1,ACKnum=y+1,序号seq=x+1),发送完毕后,客户端进入 ESTABLISHED 状态,当服务器端接收到这个包时,也进入 ESTABLISHED 状态。
ACK也好,ack也好,只不过是个代号而已 ACK是确认值(Acknowledgement),为1便是确认连接。 ack是确认编号(Acknowledgement Number),即接收到的上一次远端主机传来的seq然后+1,再发送给远端主机。提示远端主机已经成功接收上一次所有数据。
- Server端:
- 由于Server没有收到ACK确认,因此会重发之前的SYN+ACK(默认重发五次,之后自动关闭连接进入CLOSED状态),Client收到后会重新传ACK给Server。
- Client端,两种情况:
- 在Server进行超时重发的过程中,如果Client向服务器发送数据,数据头部的ACK是为1的,所以服务器收到数据之后会读取 ACK number,进入 establish 状态
- 在Server进入CLOSED状态之后,如果Client向服务器发送数据,服务器会以RST包(异常终止报文)应答。
思路: TCP 握手为什么不能是两次,为什么不能是四次呢?为了方便理解,我们以男孩子和女孩子谈恋爱为例子:两个人能走到一起,最重要的事情就是相爱,就是我爱你,并且我知道,你也爱我,接下来我们以此来模拟三次握手的过程:
为什么握手不能是两次呢? 如果只有两次握手,女孩子可能就不知道,她的那句我也爱你,男孩子是否收到,恋爱关系就不能愉快展开。
为什么握手不能是四次呢? 因为握手不能是四次呢?因为三次已经够了,三次已经能让双方都知道:你爱我,我也爱你。而四次就多余了。
总结: 确保可靠的通信通道,让双方都确认对方和自己的接收和发送功能是正常的。 将三次握手通俗的说。
- 第一次握手,Server知道Client的发送能力和自己的接收能力是正常的。
- 第二次握手,Client知道Server的发送和接收能力和自己的发送和接收能力是正常的,但是Server还不知道我的接收和他的发送能力正常与否。
- 第三次握手,Client回馈,让Server知道自己的发送能力和Client的接收能力正常。
思路: TCP 的四次挥手,也是最重要的知识点,一般跟三次握手会一起考的,必须得记住。
- Client状态变化:Fin-Wait-1 -> Fin-Wait-2 -> Time-Wait -> Closed
- Server状态变化:Close-Wait -> Last-Ack -> Closed
具体流程:
- 第一次挥手:客户端发送连接释放报文FIN=1,序号(握手时初始序号 + 发送的字节数据数量 + 1)seq=u,发送完毕后,客户端进入FIN_WAIT_1状态。
- 第二次挥手:服务器发出确认收到报文ACK=1,确认号ack=u+1,序列号(握手时初始序号 + 回复的字节数据)seq=v,发送完毕后,服务器端进入CLOSE_WAIT状态,客户端接收到这个确认包之后,进入FIN_WAIT_2状态。
- 第三次挥手:关闭连接,发送连接释放报文FIN=1,确认号ack=u+1,初始序号seq=w,发送完毕后,服务器端进入LAST_ACK状态,等待来自客户端的最后一个 ACK。
- 第四次挥手: 客户端接收到来自服务器端的关闭请求,发回确认收到报文ACK=1,确认序号seq=w+1,初始序号ack=u+1,客户端进入 TIME_WAIT 状态,等待了某个固定时间(两个最大段生命周期,2MSL,2 Maximum Segment Lifetime)之后,没有收到服务器端的 ACK ,认为服务器端已经正常关闭连接,于是自己也关闭连接,进入 CLOSED 状态。服务器端接收到这个确认包之后,关闭连接,进入 CLOSED 状态。
思路: TCP 挥手为什么需要四次呢?为了方便大家理解,再举个生活的例子吧。
★ 小明和小红打电话聊天,通话差不多要结束时,小红说,“我没啥要说的了”。小明回答,“我知道了”。但是小明可能还有要说的话,小红不能要求小明跟着她自己的节奏结束通话,于是小明可能又叽叽歪歪说了一通,最后小明说,“我说完了”,小红回答,“我知道了”,这样通话才算结束。
总结:
Server端可能还有数据没有发送完毕。Client发出连接释放通知,Server确认收到后,Client就进入半关闭状态(只收消息不发消息),Server把未发完的数据发送完毕后,发送连接释放通知,Client确认后就关闭连接。
思路: 这个问得频率特别高。去面试前,一定要把这道题拿下哈。
2MSL,two Maximum Segment Lifetime,即两个最大段生命周期。假设主动发起挥手的是客户端,那么需要 2MSL 的原因是:
- 1. 为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 这个 ACK 报文段有可能丢失,因而使处在LAST-ACK状态的服务端就收不到对已发送的FIN + ACK报文段的确认。服务端会超时重传这个 FIN+ACK 报文段,而客户端就能在 2MSL 时间内(超时 + 1MSL 传输)收到这个重传的 FIN+ACK 报文段。接着客户端重传一次确认,重新启动 2MSL 计时器。最后,客户端和服务器都正常进入到CLOSED状态。(简述:防止ack报文丢失,Server再次发送Fin报文,一来一回最长时间就是2MSL)
- 2. 防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个 ACK 报文段后,再经过时间 2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。
从服务器来讲,短时间内关闭了大量的Client连接,就会造成服务器上出现大量的TIME_WAIT连接,严重消耗着服务器的资源,此时部分客户端就会显示连接不上。
从客户端来讲,客户端TIME_WAIT过多,就会导致端口资源被占用,因为端口就65536个,被占满就会导致无法创建新的连接。
解决办法:
- 服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态,此套接字选项告诉内核,即使此端口正忙(处于TIME_WAIT状态),也请继续并重用它。
- 调整系统内核参数,修改/etc/sysctl.conf文件,即修改
net.ipv4.tcp_tw_reuse 和 tcp_timestamps
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
- 强制关闭,发送 RST 包越过TIME_WAIT状态,直接进入CLOSED状态。
TIME_WAIT 是主动断开连接的一方会进入的状态,一般情况下,都是客户端所处的状态;服务器端一般设置不主动关闭连接。
TIME_WAIT 需要等待 2MSL,在大量短连接的情况下,TIME_WAIT会太多,这也会消耗很多系统资源。对于服务器来说,在 HTTP 协议里指定 KeepAlive(浏览器重用一个 TCP 连接来处理多个 HTTP 请求),由浏览器来主动断开连接,可以一定程度上减少服务器的这个问题。
TCP 是面向流,没有界限的一串数据。TCP 底层并不了解上层业务数据的具体含义,它会根据 TCP 缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被 TCP 拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的 TCP 粘包和拆包问题。
为什么会产生粘包和拆包呢?
- 要发送的数据小于 TCP 发送缓冲区的大小,TCP 将多次写入缓冲区的数据一次发送出去,将会发生粘包;
- 接收数据端的应用层没有及时读取接收缓冲区中的数据,将发生粘包;
- 要发送的数据大于 TCP 发送缓冲区剩余空间大小,将会发生拆包;
- 待发送数据大于 MSS(最大报文长度),TCP 在传输前将进行拆包。即 TCP 报文长度 - TCP 头部长度 > MSS。
解决方案:
- 发送端将每个数据包封装为固定长度
- 在数据尾部增加特殊字符进行分割
- 将数据分为两部分,一部分是头部,一部分是内容体;其中头部结构大小固定,且有一个字段声明内容体的大小。
TCP 三次握手,发送端和接收端进入到 ESTABLISHED 状态,它们即可以愉快地传输数据啦。
但是发送端不能疯狂地向接收端发送数据,因为接收端接收不过来的话,接收方只能把处理不过来的数据存在缓存区里。如果缓存区都满了,发送方还在疯狂发送数据的话,接收方只能把收到的数据包丢掉,这就浪费了网络资源啦。
★ TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量,这就是流量控制。
TCP 通过滑动窗口来控制流量,我们看下流量控制的简要流程吧:
首先双方三次握手,初始化各自的窗口大小,均为 400 个字节。
TCP 的流量控制
- 假如当前发送方给接收方发送了 200 个字节,那么,发送方的
SND.NXT
会右移 200 个字节,也就是说当前的可用窗口减少了 200 个字节。 - 接受方收到后,放到缓冲队列里面,REV.WND =400-200=200 字节,所以 win=200 字节返回给发送方。接收方会在 ACK 的报文首部带上缩小后的滑动窗口 200 字节
- 发送方又发送 200 字节过来,200 字节到达,继续放到缓冲队列。不过这时候,由于大量负载的原因,接受方处理不了这么多字节,只能处理 100 字节,剩余的 100 字节继续放到缓冲队列。这时候,REV.WND = 400-200-100=100 字节,即 win=100 返回发送方。
- 发送方继续干活,发送 100 字节过来,这时候,接受窗口 win 变为 0。
- 发送方停止发送,开启一个定时任务,每隔一段时间,就去询问接受方,直到 win 大于 0,才继续开始发送。
思路讲解: 我以前面试的时候,面试官就问我什么是半连接队列、什么是全连接队列,哈哈。我们需要掌握半连接队列、全连接对列是啥,还需要清楚半连接队列和 SYN Flood 攻击有什么关系。
我的答案如下:
TCP 进入三次握手前,服务端会从CLOSED状态变为LISTEN状态, 同时在内部创建了两个队列:半连接队列(SYN 队列)和全连接队列(ACCEPT 队列)。
什么是半连接队列(SYN 队列) 呢? 什么是全连接队列(ACCEPT 队列) 呢?回忆下 TCP 三次握手的图:
三次握手
- TCP 三次握手时,客户端发送 SYN 到服务端,服务端收到之后,便回复ACK 和 SYN,状态由LISTEN 变为 SYN_RCVD,此时这个连接就被推入了SYN 队列,即半连接队列。
- 当客户端回复 ACK, 服务端接收后,三次握手就完成了。这时连接会等待被具体的应用取走,在被取走之前,它被推入 ACCEPT 队列,即全连接队列。
SYN Flood 是一种典型的 DDos 攻击,它在短时间内,伪造不存在的 IP 地址, 向服务器大量发起 SYN 报文。当服务器回复 SYN+ACK 报文后,不会收到 ACK 回应报文,导致服务器上建立大量的半连接半连接队列满了,这就无法处理正常的 TCP 请求啦。
那么有哪些方案应对呢?主要有 syn cookie和SYN Proxy 防火墙等。
★
- syn cookie:在收到 SYN 包后,服务器根据一定的方法,以数据包的源地址、端口等信息为参数计算出一个 cookie 值作为自己的 SYNACK 包的序列号,回复 SYN+ACK 后,服务器并不立即分配资源进行处理,等收到发送方的 ACK 包后,重新根据数据包的源地址、端口计算该包中的确认序列号是否正确,如果正确则建立连接,否则丢弃该包。
- SYN Proxy 防火墙:服务器防火墙会对收到的每一个 SYN 报文进行代理和回应,并保持半连接。等发送方将 ACK 包返回后,再重新构造 SYN 包发到服务器,建立真正的 TCP 连接。
思路讲解: TCP 滑动窗口是个高频考点,我们需要知道 TCP 报文首部有个字段win控制窗口大小的,同时也需要掌握,滑动窗口是怎么滑的。
TCP 发送一个数据,如果需要收到确认应答,才会发送下一个数据。这样的话就会有个缺点:效率会比较低。
★ 这就好像我们面对面在聊天,你说完一句,我应答之后,你才能说下一句。那么,如果我在忙其他事情,没有能够及时回复你呢?你说完一句后,要等到我忙完回复你,你才说下句,这显然不现实,效率太低。
为了解决这个问题,TCP 引入了窗口,它是操作系统开辟的一个缓存空间。窗口大小值表示无需等待确认应答,而可以继续发送数据的最大值。
TCP 头部有个字段叫 win,也即那个16 位的窗口大小,它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据,这样对方就可以控制发送数据的速度,从而达到流量控制的目的。
★ 通俗点讲,就是接受方每次收到数据包,在发送确认报文的时候,同时告诉发送方,自己的缓存区还有多少空余空间,缓冲区的空余空间,我们就称之为接受窗口大小。这就是 win。
TCP 滑动窗口分为两种: 发送窗口和接收窗口。发送端的滑动窗口包含四大部分,如下:
- 已发送且已收到 ACK 确认
- 已发送但未收到 ACK 确认
- 未发送但可以发送
- 未发送也不可以发送
- 虚线矩形框,就是发送窗口。
- SND.WND: 表示发送窗口的大小, 上图虚线框的格子数是 14 个,即发送窗口大小是 14。
- SND.NXT:下一个发送的位置,它指向未发送但可以发送的第一个字节的序列号。
- SND.UNA: 一个绝对指针,它指向的是已发送但未确认的第一个字节的序列号。
接收方的滑动窗口包含三大部分,如下:
- 已成功接收并确认
- 未收到数据但可以接收
- 未收到数据并不可以接收的数据
- 虚线矩形框,就是接收窗口。
- REV.WND: 表示接收窗口的大小, 上图虚线框的格子就是 9 个。
- REV.NXT: 下一个接收的位置,它指向未收到但可以接收的第一个字节的序列号。
思路讲解: TCP 拥塞机制也是个高频考点,需要掌握它跟流量控制的区别,也需要掌握拥塞控制的这几种算法:慢启动算法、拥塞避免、快速重传、快速恢复算法。
拥塞控制是作用于网络的,防止过多的数据包注入到网络中,避免出现网络负载过大的情况。它的目标主要是最大化利用网络上瓶颈链路的带宽。它跟流量控制又有什么区别呢?流量控制是作用于接收者的,根据接收端的实际接收能力控制发送速度,防止分组丢失的。
我们可以把网络链路比喻成一根水管,如果我们想最大化利用网络来传输数据,那就是尽快让水管达到最佳充满状态。
发送方维护一个拥塞窗口 cwnd(congestion window) 的变量,用来估算在一段时间内这条链路(水管)可以承载和运输的数据(水)的数量。它大小代表着网络的拥塞程度,并且是动态变化的,但是为了达到最大的传输效率,我们该如何知道这条水管的运送效率是多少呢?
一个比较简单的方法就是不断增加传输的水量,直到水管快要爆裂为止(对应到网络上就是发生丢包),用 TCP 的描述就是:
★ 只要网络中没有出现拥塞,拥塞窗口的值就可以再增大一些,以便把更多的数据包发送出去,但只要网络出现拥塞,拥塞窗口的值就应该减小一些,以减少注入到网络中的数据包数。
实际上,拥塞控制主要有这几种常用算法
- 慢启动
- 拥塞避免
- 拥塞发生
- 快速恢复
cwnd初始值为1,每个轮次cwnd加倍
慢启动算法,表面意思就是,别急慢慢来。它表示 TCP 建立连接完成后,一开始不要发送大量的数据,而是先探测一下网络的拥塞程度。由小到大逐渐增加拥塞窗口的大小,如果没有出现丢包,每收到一个 ACK,就将拥塞窗口 cwnd 大小就加 1(单位是 MSS)。每轮次发送窗口增加一倍,呈指数增长,如果出现丢包,拥塞窗口就减半,进入拥塞避免阶段。
- TCP 连接完成,初始化 cwnd = 1,表明可以传一个 MSS 单位大小的数据。
- 每当收到一个 ACK,cwnd 就加一;
- 每当过了一个 RTT,cwnd 就增加一倍; 呈指数让升
为了防止 cwnd 增长过大引起网络拥塞,还需设置一个慢启动阀值 ssthresh(slow start threshold)状态变量。当cwnd
到达该阀值后,就好像水管被关小了水龙头一样,减少拥塞状态。即当cwnd >ssthresh时,进入了拥塞避免算法。
慢开始门限ssthresh,当cwnd>ssthresh时,进入拥塞避免,让cwnd每个轮次+1。出现超时,就令ssthresh = cwnd/2,重新进行慢开始。
一般来说,慢启动阀值 ssthresh 是 65535 字节,cwnd
到达慢启动阀值后
- 每收到一个 ACK 时,cwnd = cwnd + 1/cwnd
- 当每过一个 RTT 时,cwnd = cwnd + 1
接收方只对最后一个收到的有序报文段进行确认,若发送方介绍重复确认,就判断下一个报文段丢失,执行快重传,即立即重传下一报文段。
当网络拥塞发生丢包时,会有两种情况:
- RTO 超时重传
- 快速重传
如果是发生了RTO 超时重传,就会使用拥塞发生算法
- 慢启动阀值 sshthresh = cwnd /2
- cwnd 重置为 1
- 进入新的慢启动过程
这真的是辛辛苦苦几十年,一朝回到解放前。其实还有更好的处理方式,就是快速重传。发送方收到 3 个连续重复的 ACK 时,就会快速地重传,不必等待RTO 超时再重传。
慢启动阀值 ssthresh 和 cwnd 变化如下:
- 拥塞窗口大小 cwnd = cwnd/2
- 慢启动阀值 ssthresh = cwnd
- 进入快速恢复算法
若丢失个别报文段,执行快恢复,令ssthresh = cwnd/2, cwnd = ssthresh,直接进入拥塞避免。
快速重传和快速恢复算法一般同时使用。快速恢复算法认为,还有 3 个重复 ACK 收到,说明网络也没那么糟糕,所以没有必要像 RTO 超时那么强烈。
正如前面所说,进入快速恢复之前,cwnd 和 sshthresh 已被更新:
- cwnd = cwnd /2 - sshthresh = cwnd
然后,真正的快速算法如下:
- cwnd = sshthresh + 3
- 重传重复的那几个 ACK(即丢失的那几个数据包)
- 如果再收到重复的 ACK,那么 cwnd = cwnd +1
- 如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK,表明恢复过程已经结束,可以再次进入了拥塞避免的算法了。
总结: 拥塞控制是为了防止过多数据注入网络,导致网络过载。TCP的拥塞控制采用四个算法实现:慢开始、拥塞避免、快重传、快恢复。 发送方维护一个拥塞窗口(cwnd)的状态变量。
- 慢开始:cwnd初始值为1,每个轮次cwnd加倍
- 拥塞避免:慢开始门限ssthresh,当cwnd>ssthresh时,进入拥塞避免,让cwnd每个轮次+1。出现超时,就令ssthresh = cwnd/2,重新进行慢开始。
- 快重传:接收方只对最后一个收到的有序报文段进行确认,若发送方介绍重复确认,就判断下一个报文段丢失,执行快重传,即立即重传下一报文段。
- 快恢复:若丢失个别报文段,执行快恢复,令ssthresh = cwnd/2, cwnd = ssthresh,直接进入拥塞避免。
思路: 这道题,校招的时候,问的概率高点,概念性的东西,TCP 是面向连接,而 UDP 是无连接。
| 类型 | 特点 | | | 性能 | |
应用场景 |
首部字节 | | --- | --- | --- | --- | --- | --- | --- | --- | | | 是否面向链接 | 传输可靠性 | 传输形式 | 传输效率 | 消耗资源 | | | | TCP | 面向连接 | 可靠 | 字节流 | 慢 | 多 | 要求通信数据可靠 (文件/邮件传输) | 20~60 | | UDP | 无连接 | 不可靠 | 数据报文段 | 快 | 少 | 要求通信速度高 (视频/语音传输) | 8 (由4个字段组成) |
总结:
- TCP:面向连接的可靠交付,以字节流传输,效率低,耗费资源少,适用于对通信数据严格的场景,如文件传输。首部20-60字节。
- UDP:无连接的尽最大努力交付,以数据报文段传输,速度快,耗费资源少,适用于对通信速度要求高的场景,如在线视频。首部8个字节。
- TCP需要三次握手,建立会话需要时间;
- TCP在网络拥塞时,会调整滑动窗口大小,影响传输速度;
- UDP无连接,没有拥塞控制,会以恒定速度发送数据,缺点是造成丢包,优点是实时性好。
- 发生丢包,就立即发送冗余包,尽快恢复数据;
- 建立长期参考帧,解决连贯性问题;
- 发生网络抖动,降低码率,保证传输数据小于网络带宽。
思路: TCP 是可靠的连接,为什么具有可靠性呢?记住这些点:连接和断开的可靠性(三次握手,四次挥手)、有状态(哪些数据发送了,哪些没发)、可控制(超时重传、流量控制、拥塞控制等)。
- 首先,TCP 的连接是基于三次握手,而断开则是基于四次挥手。确保连接和断开的可靠性。
- 其次,TCP 的可靠性,还体现在有状态;TCP 会记录哪些数据发送了,哪些数据被接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
- 再次,TCP 的可靠性,还体现在可控制。它有数据包校验、ACK 应答、超时重传 (发送方)、失序数据重传(接收方)、丢弃重复数据、流量控制(滑动窗口)和拥塞控制等机制。
- 16 位端口号:源端口号,主机该报文段是来自哪里;目标端口号,要传给哪个上层协议或应用程序
- 32 位序号:一次 TCP 通信(从 TCP 连接建立到断开)过程中某一个传输方向上的字节流的每个字节的编号。
- 32 位确认号:用作对另一方发送的 tcp 报文段的响应。其值是收到的 TCP 报文段的序号值加 1。
- 4 位头部长度:表示 tcp 头部有多少个 32bit 字(4 字节)。因为 4 位最大能标识 15,所以 TCP 头部最长是 60 字节。
- 6 位标志位:URG(紧急指针是否有效),ACk(表示确认号是否有效),PSH(缓冲区尚未填满),RST(表示要求对方重新建立连接),SYN(建立连接消息标志接),FIN(表示告知对方本端要关闭连接了)
- 16 位窗口大小:是 TCP 流量控制的一个手段。这里说的窗口,指的是接收通告窗口。它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据,这样对方就可以控制发送数据的速度。
- 16 位校验和:由发送端填充,接收端对 TCP 报文段执行 CRC 算法以检验 TCP 报文段在传输过程中是否损坏。注意,这个校验不仅包括 TCP 头部,也包括数据部分。这也是 TCP 可靠传输的一个重要保障。
- 16 位紧急指针:一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此,确切地说,这个字段是紧急指针相对当前序号的偏移,不妨称之为紧急偏移。TCP 的紧急指针是发送端向接收端发送紧急数据的方法。
如果发送方疯狂地向接收方发送很小的数据包,比如一次就发送 1 个字节,那么显然会有问题。
TCP/IP 协议中,无论发送多少数据,总是需要在数据前面加上协议头,同时,对方接收到数据,也需要发送 ACK 表示确认。为了尽可能的利用网络带宽,TCP 总是希望尽可能的发送足够大的数据。Nagle 算法就是为了尽可能发送大块数据,避免网络中充斥着许多小数据块。
Nagle 算法:任意时刻,最多只能有一个未被确认的小段。所谓 “小段”,指的是小于 MSS 尺寸的数据块,所谓 “未被确认”,是指一个数据块发送出去后,没有收到对方发送的 ACK 确认该数据已收到。
Nagle 算法的实现规则:
- 如果包长度达到 MSS,则允许发送;
- 如果该包含有 FIN,则允许发送;
- 设置了 TCP_NODELAY 选项,则允许发送;
- 未设置 TCP_CORK 选项时,若所有发出去的小数据包(包长度小于 MSS)均被确认,则允许发送;
- 上述条件都未满足,但发生了超时(一般为 200ms),则立即发送。
如果接受方刚接收到发送方的数据包,在很短很短的时间内,又接收到第二个包。那么请问接收方是一个一个地回复好点,还是合在一起回复好呢?
接收方收到数据包后,如果暂时没有数据要发给对端,它可以等一小段时间,再确认(Linux 上默认是 40ms)。如果这段时间刚好有数据要传给对端,ACK 就随着数据传输,而不需要单独发送一次 ACK。如果超过时间还没有数据要发送,也发送 ACK,避免对端以为丢包。
但是有些场景不能用延迟确认,比如发现了乱序包、接收到了大于一个 frame 的报文,且需要调整窗口大小等。
一般情况下,Nagle 算法和延迟确认不能一起使用,Nagle 算法意味着延迟发,延迟确认意味着延迟接收,酱紫就会造成更大的延迟,会产生性能问题。
思路讲解: TCP 的重传机制,也是道非常高频的面试题。重传包括超时重传、快速重传、带选择确认的重传(SACK)、重复 SACK 四种。
超时重传,是 TCP 协议保证数据可靠性的另一个重要机制,其原理是在发送某一个数据以后就开启一个计时器,在一定时间内如果没有得到发送的数据报的 ACK 报文,那么就重新发送数据,直到发送成功为止。
这个一定时间内,一般是多少比较合理呢?来看下什么叫RTT(Round-Trip Time,往返时间)。
RTT 就是数据完全发送完,到收到确认信号的时间,即数据包的一次往返时间。超时重传时间,就是 RTO(Retransmission Timeout)。
那么,RTO 到底设置多大呢?
- 如果 RTO 设置很大,等了很久都没重发,这样肯定就不行。
- 如果 RTO 设置很小,那很可能数据都没有丢失,就开始重发了,这会导致网络阻塞,从而恶性循环,导致更多的超时出现。
一般来说,RTO 略微大于 RTT,效果是最佳的。其实,RTO 有个标准方法的计算公式,也叫Jacobson / Karels 算法。一起来看下吧:
1. 首先计算 SRTT(即计算平滑的 RTT)
SRTT = (1 - α) * SRTT + α * RTT // 求 SRTT 的加权平均
2. 其次,计算 RTTVAR (round-trip time variation)
RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) // 计算 SRTT 与真实值的差距
3. 最后,得出最终的 RTO
RTO = µ * SRTT + ∂ * RTTVAR = SRTT + 4·RTTVAR
一般情况,α、β等的参数取值如下:
α = 0.125,β = 0.25, μ = 1,∂ = 4
别问这些参数是怎么来的,它们是大量实践,调出的最优参数。
超时重传不是十分完美的重传方案,它有这些缺点:
- 当一个报文丢失时,会等待一定的超时周期,才重传分组,增加了端到端的时延。
- 当一个报文丢失时,在其等待超时的过程中,可能会出现这种情况:其后的报文段已经被接收端接收但却迟迟得不到确认,发送端会认为也丢失了,从而引起不必要的重传,既浪费资源也浪费时间。
并且,对于 TCP,如果发生一次超时重传,时间间隔下次就会加倍。
总结: 超时重传:若一个已经发送的报文段在超时时间内没有收到确认,就重传这个报文段。超时时间RTO略大于加权往返时间RTTs。往返时间RTT指一个报文段从发送再到接收到确认所经过的时间。
其实可以使用快速重传,来解决超时重发的时间等待问题。它不以时间驱动,而是以数据驱动。它是基于接收端的反馈信息来引发重传的。快速重传流程如下:
发送方发送了 1,2,3,4,5,6 份数据:
- 第一份 Seq=1 先送到了,于是就 Ack 回 2;
- 第二份 Seq=2 也送到了,于是 ACK 回 3;
- 第三份 Seq=3 由于网络等某些原因,没送到;
- 第四份 Seq=4 送到了,但是由于 Seq=3 没收到。因此 ACK 还是回 3;
- 后面的 Seq=5,6 的也送到了,ACK 还是回复 3,因为 Seq=3 没有收到。
- 发送方连着收到三个重复冗余 ACK=3 的确认(其实是 4 个哈,但是因为前面的一个是正常的 ACK,后面三个才是重复冗余的),于是知道哪个报文段在传输过程中丢失了;发送方在定时器过期之前,重传该报文段。
- 最后,接收方收到了 Seq=3,此时因为 Seq=4,5,6 都收到了,于是它回 ACK=7。
但是呢,快速重传也可能有问题:ACK 只向告知发送方,最大的有序报文段。到底是哪个报文丢失了呢?并不确定!那到底该重传多少个包呢?
★ 是重传 Seq=3 ?还是重传 Seq=3、Seq=4、Seq=5、Seq=6 呢?因为发送端并不清楚这三个连续的 ACK=3 是谁传回来的。
为了解决:应该重传多少个包的问题? TCP 提供了带选择确认的重传(即 SACK,Selective Acknowledgment)。
★ SACK 机制就是,在快速重传的基础上,接收方返回最近收到报文段的序列号范围,这样发送方就知道接收方哪些数据包是没收到的。这样就很清楚应该重传哪些数据包啦。
SACK 机制
如上图中,发送方收到了三次同样的 ACK=30 的确认报文,于是就会触发快速重发机制,通过 SACK 信息发现只有30~39
这段数据丢失,于是重发时,就只选择了这个30~39
的 TCP 报文段进行重发。
★ D-SACK,英文是 Duplicate SACK,是在 SACK 的基础上做了一些扩展,主要用来告诉发送方,有哪些数据包,自己重复接受了。DSACK 的目的是帮助发送方判断,是否发生了包失序、ACK 丢失、包重复或伪重传。让 TCP 可以更好的做网络流控。来看个图吧:
UDP的首部只有8个字节,源端口号、目的端口号、长度和校验和各两个字节
参考资料 [1] http 的长连接和短连接(史上最通俗!): https://www.jianshu.com/p/3fc3646fad80 [2] Cookie 和 Session 的区别: https://zhuanlan.zhihu.com/p/66754258 [3] ARP 协议的工作机制详解: http://c.biancheng.net/view/6388.html [4] ARP 协议工作流程: https://blog.csdn.net/qq_44041062/article/details/109844155 [5]一文搞定所有计算机网络面试题: https://segmentfault.com/a/1190000038526729
[