面经-计算机网络
计算机网络
常用术语
报文段(segment):运输层分组,TCP和UDP的分组
数据包(datagram):网络层分组
用户从输入网址到页面显示,期间发生了什么
- 首先浏览器会解析url,根据请求信息生成对应的http请求报文;包括,请求行(get等请求方法),请求头(user-agent等键值对),空行和请求体(仅在post(向阿里云oss中传输图片等文件)和put(变更数据)等方法中存在)
详解:在爬虫中我常用的是get方法,但实际上,在postman中给出的,可以在java中设置的方法有很多,最常见的有crud,分别对应的是
java中设置的方法 | http对应的请求行方法 |
---|---|
create | post,put(仅限文本) |
read | get |
update | put |
delete | delete |
post和put的区别?
就是仅限新增和包含变更的区别
然后域名服务器要对输入的域名(muyi.ltd)进行解析,将其解析为ipv4地址(47.103.74.175)
之后客户端和服务端之间通过tcp三次握手建立联系,服务端根据请求报文返回信息
TCP四次挥手断开连接:浏览器与服务器IP断开TCP连接。
客户端浏览器根据服务器返回的响应进行页面渲染展示
http请求报文和响应报文是怎样的
请求报文
请求报文是浏览器根据请求内容生成的向服务器发送的请求信息,包含请求行,请求头,空行和请求体;
请求行包括如下字段:
- 方法(Method):指定要执行的操作,如 GET、POST、PUT、DELETE 等。
- 资源路径(Resource Path):请求的资源的URI(统一资源标识符 Uniform Resource Identifier)。
- HTTP版本(HTTP Version):使用的HTTP协议版本,如 HTTP/1.1 或 HTTP/2.0。
常用的请求头
- user-agent:用于标识发起请求的客户端(如浏览器、爬虫、应用程序等)。它通常包含以下信息:
1 | 软件名称(如 `Mozilla`、`Chrome`) |
- Accept:客户端能够处理的媒体类型。
- Accept-Encoding:客户端能够解码的内容编码。
- Cookie:浏览网页后存储在计算机的缓存文件;
- If-None-Match,If-Modified-Since:协商缓存相关请求头。
空行是请求头部和请求主体之间的空行,用于分隔请求头部和请求主体。而请求体通常用于 POST 和 PUT 请求,包含发送给服务器的数据。
响应报文
HTTP响应报文是服务器向客户端返回的数据格式,用于传达服务器对客户端请求的处理结果以及相关的数据。响应报文包括状态行,响应头,空行和请求体;
状态行包含HTTP版本、状态码和状态消息。例如:HTTP/1.1 200 OK
响应头部也是以键值对的形式提供的额外信息,类似于请求头部,用于告知客户端有关响应的详细信息。一些常见的响应头部字段包括:
- Content-Type:指定响应主体的媒体类型。
- Etag、Last-Modified:对应协商缓存相关响应头。
- cache-control:强缓存响应头。
- Server:服务器的信息,如nginx。
空行(Empty Line)在响应头和响应体之间,表示响应头的结束。而响应体是服务端实际传输的数据,可以是文本、HTML页面、图片、视频等,也可能为空。
重要端口号
80 443 53 3306 1521 8080
端口名 | 端口号 | 端口功能 |
---|---|---|
FTP | 21 | 文件传输协议 |
SSH | 22 | 远程登录 |
DNS | 53 | 域名解析服务 |
HTTP | 80 | 原文传输 |
HTTPS | 443 | 加密传输 |
Oracle | 1521 | 数据库服务器 |
MySQL | 3306 | 数据库服务器 |
Tomcat | 8080 | JSP应用服务器 |
Nacos | 8848 | 微服务配置管理中心 |
重要状态码
状态码 | 功能 |
---|---|
200 | 成功 |
304 | 服务器中的资源未修改(用于浏览器协商缓存策略) |
404 | 请求的资源在服务器上未找到,也有可能是客户端地址输入的不对 |
补充

说明
常用的包括以下几个:
- 200:表示客户端请求成功
- 201:创建了新资源。
- 204 :无内容,服务器成功处理请求,但未返回任何内容。
- 301:永久重定向
- 302: 临时重定向
- 304:请求的内容没有修改过,所以服务器返回此响应时,不会返回网页内容,而是使用缓存
- 401:请求需要身份验证
- 403:请求的对应资源禁止被访问
- 404:服务器无法找到对应资源
- 500:服务器内部错误
- 503: 服务器目前无法使用(由于超载或停机维护)
TCP/IP模型与OSI模型

OSI(Open Systems Interconnection)是国际标准化组织(ISO)在1984年发布的,目的是创建一个标准化的网络通信框架,以便不同厂商的设备可以相互操作。
物理层(Physical Layer):主要用于比特流传输的物理连接,如光纤、网线、无线电波等。
数据链路层(Data Link Layer) :同一个数据链路内的帧传输,对应物理地址(MAC)寻址,错误检测与纠正,如以太网等。
网络层(Network Layer) :负责端到端的通信,主要用于路径选择和逻辑地址(IP)管理。
传输层(Transport Layer) :用于可靠传输,流量控制,错误检测,如TCP, UDP等。
会话层(Session Layer):建立、管理、终止会话,如NetBIOS、RPC等
表示层(Presentation Layer) :用于数据格式转换、加密、解密,如JPEG, MPEG, SSL/TLS等。
应用层(Application Layer):用户交互界面,提供网络服务,如HTTP、FTP等。
数据链路层和网络层
数据链路层负责相邻设备(同一链路)之间的通信,即从电脑和交换机之间、路由器和路由器之间的直接数据传输。
网络层负责端到端的通信(跨多个网络)
可以把数据传输比喻成寄快递:
- 数据链路层 相当于快递员在同一个城市内派送包裹,按照门牌号(MAC 地址)找到收件人。
- 网络层 相当于快递公司的物流系统,负责决定包裹从上海到北京要经过哪些中转站(路由)。
会话层
协议 | 功能 |
---|---|
RPC(远程过程调用协议) | 允许程序在远程计算机上执行某个过程,比如分布式系统。 |
SQL(结构化查询语言) | 通过会话层维护数据库连接。 |
NetBIOS | 用于局域网中的计算机名称解析和会话管理。 |
SMPP(短消息对等协议) | 用于短信传输,比如短信网关的通信。 |
PPTP(点对点隧道协议) | 用于VPN连接,建立加密隧道。 |
强缓存和协商缓存
为了减少资源访问次数,加快资源访问速度,浏览器对请求体中的资源文件有一个缓存功能,该缓存功能包含两种缓存策略,分别是强缓存和协商缓存,优先级强缓存大于协商缓存
强缓存
强缓存就是浏览器本地根据服务器设置的过期时间来判断是否使用缓存,未过期则从本地缓存里拿资源,已过期则重新请求服务器获取最新资源。
优先级cache-control大于expires
cache-control (http1.1及以后)
max-age
: max-age=300,表示在接下来的五分钟内,不会再请求服务器资源,而只使用缓存在磁盘内的资源
expires(http1.0)
一个未来时间,代表资源的有效截止期,但是系统时间可以被改变
协商缓存
协商缓存则是浏览器本地每次都向服务器发起请求,由服务器来告诉浏览器是从缓存里拿资源还是返回最新资源给浏览器使用,如果服务器内资源不变,则返回304状态码,使用本地缓存的资源,否则返回200状态码,并更新相应的请求头内容
为方便描述,请求报文中的请求行为请求头,响应报文中的请求行为响应头
优先级Etag大于Last-Modified
Etag
响应头: Etag
请求头:If-None-Match (标识符字符串 Etag)
Etag为标识符字符串,表示文件唯一标识,只要文件内容改动,ETag就会重新计算。缓存流程和 Last-Modified 一样。
Last-Modified
响应头: Last-Modified
请求头: If-Modified-Since ( 资源修改的时间 )
浏览器第一次发请求,服务器在返回的 respone 的 header 加上 Last-Modified,表示资源的最后修改时间
再次请求资源,在 requset 的 header 加上 If-Modified-Since ,值就是上一次请求返回的 Last-Modified 值
服务器根据请求传过来的值判断资源是否有变化,没有则返回 304,有变化就正常返回资源内容,更新 Last-Modified 的值
浏览器检查状态码,304从缓存加载资源,200直接从服务器加载资源
Last-Modified 与 Etag 的对比:
- 如果我们打开文件但并没有修改其内容,Last-Modified 也会改变,而Etag则不会改变。
- Last-Modified 的时间单位为秒,如果一秒内对文件进行了多次修改,那么由于其时间单位是秒,所以Last-Modified不会改变,最终浏览器还是会去读取缓存资源,而此时缓存的资源已经过时了,但是Etag是变化的
- Etag的优先级高于Last-Modified。
总结背诵

强缓存和协商缓存是HTTP缓存机制的两种类型,它们用于减少服务器的负担和提高网页加载速度。
- 强缓存:客户端在没有向服务器发送请求的情况下,直接从本地缓存中获取资源。
Expires强缓存
:设置一个强缓存时间,此时间范围内,从内存中读取缓存并返回。但是因为Expires
判断强缓存过期的机制是获取本地时间戳,与之前拿到的资源文件中的Expires
字段的时间做比较来判断是否需要对服务器发起请求。这里有一个巨大的漏洞:各地的本地时间不一致,所以目前已经被废弃了。Cache-Control强缓存
:目前使用的强缓存是通过HTTP响应头中的Cache-Control
字段实现,通过max-age
来告诉浏览器在指定时间内可以直接使用缓存数据,无需再次请求。
- 协商缓存:当强缓存失效时,浏览器会发送请求到服务器,通过
ETag
或Last-Modified
等HTTP响应头与服务器进行验证,以确定资源是否被修改。如果资源未修改,服务器返回304 Not Modified
状态码,告知浏览器使用本地缓存;如果资源已修改,则返回新的资源,浏览器更新本地缓存。这种方式需要与服务器通信,但可以确保用户总是获取最新的内容。
基于
Last-Modified
的协商缓存Last-Modified
是资源的最后修改时间,服务器在响应头部中返回。- 当客户端读取到
Last-modified
的时候,会在下次的请求标头中携带一个字段:If-Modified-Since
,而这个请求头中的If-Modified-Since
就是服务器第一次修改时候给他的时间 - 服务器比较请求中的
If-Modified-Since
值与当前资源的Last-Modified
值,如果比对的结果是没有变化,表示资源未发生变化,返回状态码304 Not Modified
。如果比对的结果说资源已经更新了,就会给浏览器正常返回资源,返回200状态。
但是这样的协商缓存有两个缺点:
- 因为是更改文件修改时间来判断的,所以在文件内容本身不修改的情况下,依然有可能更新文件修改时间(比如修改文件名再改回来),这样,就有可能文件内容明明没有修改,但是缓存依然失效了。
- 当文件在极短时间内完成修改的时候(比如几百毫秒)。因为文件修改时间记录的最小单位是秒,所以,如果文件在几百毫秒内完成修改的话,文件修改时间不会改变,这样,即使文件内容修改了,依然不会返回新的文件。
基于ETag的协商缓存:将原先协商缓存的比较时间戳的形式修改成了比较文件指纹(根据文件内容计算出的唯一哈希值)。
ETag
是服务器为资源生成的唯一标识符(文件指纹),可以是根据文件内容计算出的哈希值,服务端将其和资源一起放回给客户端。- 客户端在请求头部的
If-None-Match
字段中携带上次响应的ETag
值。 - 服务器比较请求中的
If-None-Match
值与当前资源的ETag
值,如果匹配,表示资源未发生变化,返回状态码304 Not Modified
。如果两个文件指纹不吻合,则说明文件被更改,那么将新的文件指纹重新存储到响应头的ETag中并连带请求资源返回给客户端
Http各版本之间的差异
五大版本
HTTP 0.9 -> HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0
http 0.9
- 只支持GET请求方式
- 没有请求头概念:所以不能在请求中指定版本号,服务端也只具有返回 HTML字符串的能力
- 服务端响应之后,立即关闭TCP连接
所以只是简单返回字符串的测试版
http 1.0
- 请求方式新增了POST,DELETE,PUT,HEADER等方式
- 增添了请求头和首部字段
- 扩充了传输内容格式,图片、音视频资源、二进制等都可以进行传输
http 1.1
HTTP 1.1 是在 1.0 发布之后的半年就推出了,完善了 1.0 版本。
- 长连接:新增Connection字段,可以设置keep-alive值保持连接不断开
- 管道化:基于上面长连接的基础,管道化可以不等第一个请求响应继续发送后面的请求,但响应的顺序还是按照请求的顺序返回
- 缓存处理:新增字段cache-control
- 断点传输
http 2.0
http 3.0
HTTP1.1和HTTP1.0的区别
- 持久连接:
HTTP/1.1
默认支持持久连接,允许在一个TCP连接上发送多个HTTP请求和响应,减少了连接建立和关闭的开销。而HTTP/1.0
默认为短连接,每次请求都需要建立一个TCP连接,并通过Connection: keep-alive
头来实现持久连接。 - 管道化:
HTTP/1.1
支持管道化(不是默认开启),允许客户端在第一个请求的响应到达之前发送多个请求,这可以减少等待时间,提高效率。HTTP/1.0不支持管道化。 - 缓存控制:
HTTP1.1
引入了Etag
缓存控制策略。HTTP1.0
主要使用强缓存中的Expires
和协商缓存中的Last Modified
来作为缓存判断的标准。 - 增加状态码:
HTTP/1.1
增加了一些新的HTTP状态码,如100 Continue
,用于请求的中间响应。 Host
头:HTTP/1.1
引入了Host
头,允许客户端指定请求的主机名,这使得在同一台服务器上托管多个域名成为可能。HTTP/1.0没有这个头字段。- 带宽优化 :
HTTP1.1
在请求头引入了range
字段,它允许只请求资源的某个部分,即返回码是206(Partial Content)
,而在HTTP1.0
中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能。
HTTP2.0与HTTP1.1的区别?
- 二进制协议:
HTTP/2.0
采用二进制格式传输数据,而非HTTP/1.1
的文本格式,使得解析更高效,减少了解析时间。 - 多路复用:
HTTP/2.0
支持多路复用,允许在单个TCP连接上并行交错发送多个请求和响应,解决了HTTP/1.1
中的队头阻塞问题。 - 头部压缩:
HTTP/2.0
引入了HPACK
压缩算法,对请求和响应的头部信息进行压缩,减少了冗余头部信息的传输,提高了传输效率。 - 服务器推送:
HTTP/2.0
允许服务器主动推送资源给客户端,而不需要客户端明确请求,这可以减少页面加载时间。 - 优先级和依赖:
HTTP/2.0
允许客户端为请求设置优先级,并表达请求之间的依赖关系,资源加载更加有序。
HTTP3.0有了解过吗?
HTTP/3是HTTP协议的最新版本,它基于QUIC协议,具有以下特点:
- 无队头阻塞: QUIC 使用
UDP
协议来传输数据。一个连接上的多个stream之间没有依赖, 如果一个stream丢了一个UDP包,不会影响后面的stream,不存在 队头阻塞问题。 - 零 RTT 连接建立(Round-Trip Time 往返时间):QUIC 允许在首次连接时进行零往返时间连接建立,从而减少了连接延迟,加快了页面加载速度。
- 连接迁移:QUIC 允许在网络切换(如从 Wi-Fi 到移动网络)时,将连接迁移到新的 IP 地址,从而减少连接的中断时间。
- 向前纠错机制:每个数据包除了它本身的内容之外,还包括了部分其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装。虽然向前纠错牺牲了每个数据包可以发送数据的上限,但是减少了因为丢包导致的数据重传时间,提高了传输效率。
- 安全性:HTTP/3默认使用TLS加密,确保了数据传输的安全性。
http和https的区别
http | https | |
---|---|---|
端口 | 80 | 443 |
数据安全性 | 以明文传输 | 通过SSL/TLS协议对数据进行加密 |
搜索 | 优先展示 |
SSL:Secure Sockets Layer
TLS:Transport Layer Security
CA:Certificate Authority,证书授权
总结背诵
两者的主要区别在于安全性和数据加密:
- 加密层:
HTTPS
在HTTP
的基础上增加了SSL/TLS
协议作为加密层,确保数据传输的安全性。而HTTP
数据传输是明文的,容易受到攻击。 - HTTP 连接建立相对简单, TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后,还需进行 SSL/TLS 的握手过程,才可进入加密报文传输。
- 端口:
HTTPS
通常使用端口443
,而HTTP
使用端口80。 - HTTPS 协议中服务器需要向 CA 申请数字证书,来保证其身份是可信的。
HTTPS的工作原理(HTTPS建立连接的过程)
HTTPS
主要基于SSL/TLS
协议,确保了数据传输的安全性和完整性, 其建立连接并传输数据的过程如下:
- 密钥交换:客户端发起HTTPS请求后,服务器会发送其公钥证书给客户端。
- 证书验证:客户端会验证服务器的证书是否由受信任的证书颁发机构(
CA
)签发,并检查证书的有效性。 - 加密通信:一旦证书验证通过,客户端会生成一个随机的对称加密密钥,并使用服务器的公钥加密这个密钥,然后发送给服务器。
- 建立安全连接:服务器使用自己的私钥解密得到对称加密密钥,此时客户端和服务器都有了相同的密钥,可以进行加密和解密操作。
- 数据传输:使用对称加密密钥对所有传输的数据进行加密,确保数据在传输过程中的安全性。
- 完整性校验:SSL/TLS协议还包括消息完整性校验机制,如消息认证码,确保数据在传输过程中未被篡改。
- 结束连接:数据传输完成后,通信双方会进行会话密钥的销毁,以确保不会留下安全隐患。
get和post请求的区别
- 用途:GET请求通常用于获取数据,POST请求用于提交数据。
- 数据传输:GET请求将参数附加在URL之后,POST请求将数据放在请求体中。
- 安全性:GET请求由于参数暴露在URL中,安全性较低;POST请求参数不会暴露在URL中,相对更安全。
- 数据大小:GET请求受到URL长度限制,数据量有限;POST请求理论上没有大小限制。
- 幂等性:GET请求是幂等的,即多次执行相同的GET请求,资源的状态不会改变;POST请求不是幂等的,因为每次提交都可能改变资源状态。
- 缓存:GET请求可以被缓存,POST请求默认不会被缓存。
三点,从用途;数据大小、安全性;缓存三个方面来说就可以了。
TCP和UDP的区别
概括
- TCP是面向连接的协议,需要在数据传输前建立连接,它提供可靠的数据传输,保证数据包的顺序和完整性;UDP是无连接的,不需要建立连接。不保证数据包的顺序或完整性。
三大特点
- TCP具有拥塞控制机制,可以根据网络状况调整数据传输速率;UDP没有拥塞控制,发送速率通常固定。
- TCP通过滑动窗口机制进行流量控制,避免接收方处理不过来;UDP没有流量控制。
- TCP能够检测并重传丢失或损坏的数据包;UDP不提供错误恢复机制。
具体区别
- TCP有复杂的报文头部,包含序列号、确认号等信息;UDP的报文头部相对简单。
正是有以上特点TCP的性能开销通常比UDP大;TCP适用于需要可靠传输的应用,如网页浏览、文件传输等;UDP适用于对实时性要求高的应用,如语音通话、视频会议等。
UDP怎么实现可靠传输
UDP它不属于连接型协议,因而具有资源消耗小,处理速度快的优点,所以通常音频、视频和普通数据在传送时使用UDP较多,因为它们即使偶尔丢失一两个数据包,也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。关键在于两点,从应用层角度考虑:
(1)提供超时重传,能避免数据报丢失。
(2)提供确认序列号,可以对数据报进行确认和排序。
本端:首先在UDP数据报定义一个首部,首部包含确认序列号和时间戳,时间戳是用来计算RTT(数据报传输的往返时间),计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报,即收到对端的确认之后才发送下一个的数据报。当时间超时,本端重传数据报,同时RTO扩大为原来的两倍,重新开始计时。
对端:接受到一个数据报之后取下该数据报首部的时间戳和确认序列号,并添加本端的确认数据报首部之后发送给本端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。
TCP连接如何确保可靠性
TCP通过超时重传、拥塞控制、流量控制、差错控制(序列号、确认应答、数据校验)等机制,确保了数据传输的可靠性和效率。
- 超时重传:发送方设置一个定时器,如果在定时器超时之前没有收到确认,发送方会重传数据。
- 拥塞控制:TCP通过算法如慢启动、拥塞避免、快重传和快恢复等,来控制数据的发送速率,防止网络过载。
- 流量控制:TCP通过滑动窗口机制进行流量控制,确保接收方能够处理发送方发送的数据量。
- 序列号:每个TCP段都有一个序列号,确保数据包的顺序正确。
- 确认应答:接收方发送ACK确认收到的数据,如果发送方在一定时间内没有收到确认,会重新发送数据。
- 数据校验:TCP使用校验和来检测数据在传输过程中是否出现错误,如果检测到错误,接收方会丢弃该数据包,并等待重传。
TCP拥塞控制是怎么实现的
TCP拥塞控制可以在网络出现拥塞时动态地调整数据传输的速率,以防止网络过载。TCP拥塞控制的主要机制包括以下几个方面:
- 慢启动(Slow Start): 初始阶段,TCP发送方会以较小的发送窗口开始传输数据。随着每次成功收到确认的数据,发送方逐渐增加发送窗口的大小,实现指数级的增长,这称为慢启动。这有助于在网络刚开始传输时谨慎地逐步增加速率,以避免引发拥塞。引发拥塞是超时重传,不是快速重传。
- 拥塞避免(Congestion Avoidance): 一旦达到一定的阈值(通常是慢启动阈值),TCP发送方就会进入拥塞避免阶段。在拥塞避免阶段,发送方以线性增加的方式增加发送窗口的大小,而不再是指数级的增长。这有助于控制发送速率,以避免引起网络拥塞。
- 快速重传(Fast Retransmit): 如果发送方连续收到相同的确认,它会认为发生了数据包的丢失,并会快速重传未确认的数据包,而不必等待超时。这有助于更快地恢复由于拥塞引起的数据包丢失。
- 快速恢复(Fast Recovery): 在发生快速重传后,TCP进入快速恢复阶段。在这个阶段,发送方不会回到慢启动阶段,而是将慢启动阈值设置为当前窗口的一半,并将拥塞窗口大小设置为慢启动阈值。这有助于更快地从拥塞中恢复。
TCP流量控制是怎么实现的?
流量控制就是让发送方发送速率不要过快,让接收方来得及接收。利用滑动窗口机制就可以实施流量控制,主要方法就是动态调整发送方和接收方之间数据传输速率。
- 滑动窗口大小: 在TCP通信中,发送方的每个TCP报文段都包含一个窗口字段,该字段指示发送方可以发送多少字节的数据而不等待确认。这个窗口大小是动态调整的。
- 确认机制: 接收方会定期发送确认(ACK)报文,告知发送方已成功接收数据。这也与流量控制密切相关,因为接收方可以通过ACK报文中的窗口字段来通知发送方它的当前窗口大小。
- 接收方窗口大小: 接收方通过接收方的TCP报文中的窗口字段告诉发送方自己当前的可接收窗口大小。这是接收方缓冲区中还有多少可用空间。
- 动态调整: 发送方会根据接收方的窗口大小动态调整发送数据的速率。如果接收方的窗口大小增加,发送方可以加速发送数据。如果窗口大小减小,发送方将减缓发送数据的速率。
TCP三次握手

(1) 三次握手的过程
- 第一次握手:客户端向服务器发送一个
SYN
(同步序列编号)报文,请求建立连接,客户端进入SYN_SENT
状态。 - 第二次握手:服务器收到
SYN
报文后,如果同意建立连接,则会发送一个SYN-ACK
(同步确认)报文作为响应,同时进入SYN_RCVD
(Synchronize Received) 状态。 - 第三次握手:客户端收到服务器的
SYN-ACK
报文后,会发送一个ACK
(确认)报文作为最终响应,之后客户端和服务器都进入ESTABLISHED(建立)
状态,连接建立成功。
(2)为什么需要三次握手
通过三次握手,客户端和服务器都能够确认对方的接收和发送能力。第一次握手确认了客户端到服务器的通道是开放的;第二次握手确认了服务器到客户端的通道是开放的;第三次握手则确认了客户端接收到服务器的确认,从而确保了双方的通道都是可用的。
而如果仅使用两次握手,服务器可能无法确定客户端的接收能力是否正常,比如客户端可能已经关闭了连接,但之前发送的连接请求报文在网络上延迟到达了服务器,服务器就会主动去建立一个连接,但是客户端接收不到,导致资源的浪费。
TCP四次挥手

(1)四次挥手的过程
- 第一次挥手:客户端发送一个
FIN
报文给服务端,表示自己要断开数据传送,报文中会指定一个序列号(seq=x)
。然后,客户端进入FIN-WAIT-1
状态。 - 第二次挥手:服务端收到
FIN
报文后,回复ACK
报文给客户端,且把客户端的序列号值+1
,作为ACK报文的序列号(seq=x+1)
。然后,服务端进入CLOSE-WAIT(seq=x+1)
状态,客户端进入FIN-WAIT-2
状态。 - 第三次挥手:服务端也要断开连接时,发送
FIN
报文给客户端,且指定一个序列号(seq=y+1)
,随后服务端进入LAST-ACK
状态。 - 第四次挥手:客户端收到
FIN
报文后,发出ACK
报文进行应答,并把服务端的序列号值+1
作为ACK
报文序列号(seq=y+2)
。此时客户端进入TIME-WAIT
状态。服务端在收到客户端的ACK
报文后进入CLOSE
状态。如果客户端等待2MSL
没有收到回复,才关闭连接。
(2)为什么需要四次挥手
TCP
是全双工通信,可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。 当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后才会完全关闭 TCP
连接。因此两次挥手可以释放一端到另一端的TCP
连接,完全释放连接一共需要四次挥手。
只有通过四次挥手,才可以确保双方都能接收到对方的最后一个数据段的确认,主动关闭方在发送完最后一个ACK
后进入TIME-WAIT
状态,这是为了确保被动关闭方接收到最终的ACK
,如果被动关闭方没有接收到,它可以重发FIN
报文,主动关闭方可以再次发送ACK
。
而如果使用三次挥手,被动关闭方可能在发送最后一个数据段后立即关闭连接,而主动关闭方可能还没有接收到这个数据段的确认。
服务器不等待客户端的ack直接关闭,可能会出现客户端想要继续数据传输的情况
背诵
客户端向服务器发送 fin,服务器收到后返回ack,之后服务器向客户端发送fin,客户端收到后向服务器发送ack后等待一段时间断开连接。
HTTP的Keep-Alive是什么?TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗?
HTTP
的Keep-Alive
,是由应用层实现的,称为 HTTP 长连接
每次请求都要经历这样的过程:建立 TCP
连接 -> HTTP
请求资源 -> 响应资源 -> 释放连接,这就是HTTP短连接,但是这样每次建立连接都只能请求一次资源,所以HTTP
的 Keep-Alive
实现了使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答,避免了连接建立和释放的开销,就就是 HTTP 长连接。通过设置HTTP头Connection: keep-alive
来实现。
TCP
的Keepalive
,是由TCP
层(内核态)实现的,称为TCP
保活机制,是一种用于在TCP
连接上检测空闲连接状态的机制
当TCP
连接建立后,如果一段时间内没有任何数据传输,TCP Keepalive
会发送探测包来检查连接是否仍然有效。
DNS查询过程

DNS
(Domain Name System)用来将主机名和域名转换为IP地址, 其查询过程一般通过以下步骤:
- 本地DNS缓存检查:首先,客户端会查询本地DNS缓存,如果缓存中有对应的IP地址,则直接返回结果。
- 如果本地缓存中没有,则会向本地的DNS服务器(通常由你的互联网服务提供商(ISP)提供, 比如中国移动)发送一个DNS查询请求。
- 如果本地DNS解析器有该域名的ip地址,就会直接返回,如果没有缓存该域名的解析记录,它会向根DNS服务器发出查询请求。根DNS服务器并不负责解析域名,但它能告诉本地DNS解析器应该向哪个顶级域(.com/.net/.org)的DNS服务器继续查询。
- 本地DNS解析器接着向指定的顶级域名DNS服务器发出查询请求。顶级域DNS服务器也不负责具体的域名解析,但它能告诉本地DNS解析器应该前往哪个权威DNS服务器查询下一步的信息。
- 本地DNS解析器最后向权威DNS服务器发送查询请求。 权威DNS服务器是负责存储特定域名和IP地址映射的服务器。当权威DNS服务器收到查询请求时,它会查找
"example.com"
域名对应的IP地址,并将结果返回给本地DNS解析器。 - 本地DNS解析器将收到的IP地址返回给浏览器,并且还会将域名解析结果缓存在本地,以便下次访问时更快地响应。
- 浏览器发起连接: 本地DNS解析器已经将IP地址返回给您的计算机,您的浏览器可以使用该IP地址与目标服务器建立连接,开始获取网页内容。
CDN是什么,有什么作用?
CDN(Content Delivery Network)是一种分布式网络服务,通过将内容存储在分布式的服务器上,使用户可以从距离较近的服务器获取所需的内容,从而加速互联网上的内容传输。
- 就近访问:CDN 在全球范围内部署了多个服务器节点,用户的请求会被路由到距离最近的 CDN 节点,提供快速的内容访问。
- 内容缓存:CDN 节点会缓存静态资源,如图片、样式表、脚本等。当用户请求访问这些资源时,CDN 会首先检查是否已经缓存了该资源。如果有缓存,CDN 节点会直接返回缓存的资源,如果没有缓存所需资源,它会从源服务器(原始服务器)上获取资源,并将资源缓存到节点中,以便以后的请求。通过缓存内容,减少了对原始服务器的请求,减轻了源站的负载。
- 可用性:即使某些节点出现问题,用户请求可以被重定向到其他健康的节点。
Cookie和Session是什么?有什么区别?
(1) Cookie和Session是什么?
Cookie
和 Session
都用于管理用户的状态和身份, Cookie
通过在客户端记录信息确定用户身份,Session
通过在服务器端记录信息确定用户身份。
- Cookie
Cookie的特点是服务器在接收到来自客户端浏览器的请求之后,能够通过分析存放于请求头的Cookie
得到客户端特有的信息,从而动态生成与该客户端相对应的内容。
- Session
Session的特点是客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session
。Session 主要用于维护用户登录状态、存储用户的临时数据和上下文信息等。服务器为每个用户分配一个唯一的Session ID
。
(2) Cookie和Session的区别?
- 数据容量:
Cookie
存储容量较小,一般为几 KB。Session
存储容量较大,通常没有固定限制,取决于服务器的配置和资源。 - 安全性:由于
Cookie
存储在用户浏览器中,因此可以被用户读取和篡改。相比之下,Session 数据存储在服务器上,更难被用户访问和修改。 - 生命周期:
Cookie
可以设置过期时间,Session
依赖于会话的持续时间或用户活动。 - 传输方式:
Cookie
在每次HTTP
请求中通过请求头传送到到服务器,而Session通过Session ID
的方式经 URL 参数传递。