计算机网络常识:缓存、长短连接 网络初探、URL、客户端与服务端、域名操作 tcp 三次握手 四次挥手

缓存:

缓存是对cpu,内存的一个节约:节约的是网络带宽资源 节约服务器的性能

资源的每次下载和请求都会造成服务器的一个压力

减少网络对资源拉取的延迟 这个就是浏览器缓存的一个好处

表示这个html页面的返回是不要缓存的 忽略缓存 需要每次都到服务器上获取新的

并不是不缓存 而是提示浏览器忽略缓存

pragma:no-cache:浏览器忽略缓存 出现在响应头里面

用来控制缓存:

浏览器发起请求,先会去看有没有缓存 没有缓存直接去请求服务器去拉取资源

在有缓存,但是缓存过期的情况下

返回304的条件:

从磁盘缓存当中去获取:过期时间没有到

图片一定是设置了过期时间的 图片资源不放在服务器上 用单独的图片服务器

图片就会做一个缓存

视频类的存储在磁盘当中

三次握手 四次挥手的状态变化

状态变化是从三次握手开始的

服务器:启动--绑定--设置监听 listen()--监听先准备好 这样才是有效的

从无状态变成listen

这样开始三次握手的操作:

(1)第一次握手:客户端发起 客户端调用connect函数

rcvd:接收

第二次握手服务器发生变化 客户端收到服务器的返回页发生变化

当最后成功 客户端和服务器是一个样子 都是established

三次握手成功 双方连接建立

建立之后就可以进行通信了--进行数据传输 通信过程中tcp是没有发生任何变化的

established就是正常的通信状态

SYN==1 发起连接请求 ==0时是没有连接

三次握手:

第一次握手:建立连接时,客户端发送SYN包到服务器,并等待服务器确认。

第二次握手:服务器收到SYN包,同时自己也给客户端发送一个确认包SYN+ACK包。

第三次握手: 客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK。

此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手

四次挥手:

双方通信完毕,关闭连接时,要进行四次挥手

第一次挥手:客户端发送一个FIN包,申请断开连接,并等待服务器确认。

第二次挥手:服务端回复一个ACK包,表示接受到客户端的关闭连接请求,但现在服务端还不能马上关

闭连接,需要检查下是否还有未处理完的数据

第三次挥手:服务端处理完所有数据,给客户端发送FIN包,表示可以断开连接

第四次挥手:客户端回复ACK包,表示断开连接

http的长短连接:

短连接:每次请求都会建立连接

长连接就是只建立一次连接 多次资源请求都复用该连接 完成后关闭

网络深层知识:

浏览器请求一个网页:

客户端就是用户所用的程序:浏览器 应用程序等等都叫做客户端client

客户端client

服务端就是存储数据 存储网页的程序 还有处理数据的一个载体

服务端:数据和文件的出口 客户端就是数据的入口

后台是数据的管理

服务器就是电脑:家用电脑 配置高一点 服务器的系统带server

我们输入一个url地址,回车:就会对网址先进行dns解析 先去解析到底是什么东西

将网址转换成ip地址 然后通往服务器 这个过程会建立三次握手和四次挥手

这个就是请求网页的流程!!!!

一般来说,一个服务器承载着一个或者多个ip地址

一个网址对应一个ip地址 那为什么不直接使用ip而使用URL地址呢?

首先是方便记忆 数字不方便记忆

一个ip地址能映射出多个域名 所以ip地址是不适合用户直接接触的

计算机对数字是比较敏感的

三次握手才会真正的建立三次握手的连接 建立连接之后才能进行http请求

服务器返回,客户端收到的是html代码文件,浏览器进行解析和渲染

等到渲染页面结束,进行四次挥手

tcp/ip的这种连接方式叫做长连接

重点:

tcp在哪个层

回答下tcp的功能

tcp为什么是三次握手?不是两次四次?

如果只做两次,无法去确认客户端的接收能力

tcp面向连接 必须是双方的 如果只有两次 只是服务器建立 客户端并没有

造成连接资源的浪费

四次是没有必要的 所以没有必要进行第四次握手

TCP为什么需要4次挥手? 为什么不是三次?

如果将第二次和第三次和为一体 第二次和第三次之间是有时间延迟的

导致客户端不能及时接收:客户端会重新发送断开请求

ack和fin之间是有时差的

这个延迟是没有办法处理的 只能是把这两次都分开 这样才能达到效率最高

只有当客户端和服务器两端都确定好要断开了 才能断开

四次是最优的方案

五次会造成资源的浪费

异常状态码,400应该找前端还是后端

HTTP状态码 400 表示客户端请求存在语法或参数错误,其责任归属需要具体分析。

http是哪一层协议

osi七层协议有哪七层 tcp四层模型

tcp四层模型

物理层和数据链路层合称为网络接口层

三层交换机具有路由功能

分层:方便管理

第七层 应用层

应用层是OSI模型中的最高层,也是和用户最近的一层。它直接面向用户和应用程序,为用户提供各种网络服务和应用程序支持

第六层 表示层

负责数据格式与编码方式的转换、加密解密和数据压缩等任务。在实际的通信协议中,表示层往往与应用层或会话层结合使用,对数据进行处理和转换。

第五层 会话层

在OSI七层模型中,会话层没有单独的协议,而是利用下层协议提供的会话机制来实现数据交换。会话层的作用是管理和协调应用程序之间的对话和会话,并与表示层一起支持数据转换、加密和解密等功能。

第四层 传输层

传输层的作用是在不可靠的网络上提供可靠的数据传输服务。它负责将应用程序发送的数据分割成较小的数据段,并使用可靠的数据传输协议(如TCP)或不可靠的数据传输协议(如UDP)将这些数据段传输到目标设备。传输层还负责控制数据流量、错误恢复和拥塞控制等任务。
如果你想要稳,就选tcp,想要稳,就选UDP

第三层 网络层

负责将数据包从源主机传输到目标主机。网络层通过使用IP协议来实现这一过程,提供了路由、寻址和分组传输等功能,以确保数据能够经过多个网络进行传输,并最终到达目标主机。

第二层 数据链路层

负责将网络层传输过来的数据包进行分帧,并在物理介质上进行传输。数据链路层还提供了错误检测和纠正功能,以确保数据的可靠性。此外,数据链路层还实现了访问控制和流量控制等功能,以协调多个设备之间的数据传输。

第一层 物理层

这一层就是osi最底层了,负责将数字数据转换成物理信号并在网络中传输。其意义在于实现不同设备之间的数据传输和通信,使得计算机网络得以正常工作。物理层还定义了传输媒介、传输速率、编码方式等参数,为上层协议提供了可靠的数据传输基础。

就是进行物理连接的

get和post请求的区别

应用层的常见协议有哪些?

http状态码

常见HTTP状态码 :

1xx :100 Continue继续:客户端应继续其请求

2xx :200 OK

请求已成功,请求所希望的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。

204 No Content(无内容)

服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档。

206 Partial Content(部分内容)

服务器成功处理了部分GET请求。

3xx

301 Moved Permanently(永久重定向)

请求的资源已被永久的移动到新URL,返回信息会包括新的URL,浏览器会自动定向到新URL。今后任何新的请求都应使用新的URI代替。

302 Found(临时重定向)

与301类似。但资源只是临时被移动。表示请求的资源被分配了新的URL,希望本次访问使用新的URL。

303 See Othe(查看其他地址)

当请求者应对不同的位置进行单独的 GET 请求以检索响应时,服务器会返回此代码。对于除 HEAD 请求之外的所有请求,服务器会自动转到其他位置。

304 Not Modified(未修改)

所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。

305 Use Proxy(使用代理)

请求者只能使用代理访问请求的网页。如果服务器返回此响应,那么,服务器还会指明请求者应当使用的代理

307 Temporary Redire(临时重定向)

与303有着相同的含义,307会遵照浏览器标准不会从POST变成GET;(不同浏览器可能会出现不同的情况)。

4xx :

400 Bad Request (语法错误)

客户端请求的语法错误,服务器无法理解。

401 Unauthorized(未授权)

请求要求用户的身份认证

403 Forbidden(禁止)

服务器理解请求客户端的请求,但是拒绝执行此请求

404 Not Found(未找到)

服务器无法根据客户端的请求找到资源(网页)。除此之外,也可以在服务器拒绝请求但不想给拒绝原因时使用。

405 Method Not Allowed (方法禁用)

客户端请求中的方法被禁止。

406 Not Acceptable(不接受)

无法使用请求的内容特性来响应请求的网页。

408 Request Time-out(请求超时)

服务器等待客户端发送的请求时间过长,超时。

5xx

500Internal Server Error(服务器内部错误)

服务器遇到错误,无法完成请求。

501 Not Implemented(尚未实施)

服务器不具备完成请求的功能。例如,当服务器无法识别请求方法时,服务器可能会返回此代码。

502 Bad Gateway(错误网关)

作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应

503 Service Unavailable(服务不可用)

由于超载或系统维护,服务器暂时的无法处理客户端的请求。通常,这只是一种暂时的状态。

504 Gateway Time-out(网关超时)

服务器作为网关或代理,未及时从上游服务器接收请求。

505 HTTP Version not supported(HTTP 版本不受支持)

服务器不支持请求中所使用的 HTTP 协议版本。

相关推荐
小王子10244 小时前
Django缓存机制详解:从配置到实战应用
redis·缓存·django·rbac
Antonio9154 小时前
【Redis】Redis 数据存储原理和结构
数据库·redis·缓存
problc6 小时前
大模型API和秘钥获取地址
数据库·redis·缓存
Rover.x6 小时前
内存泄漏问题排查
java·linux·服务器·缓存
木宇(记得热爱生活)7 小时前
Qt GUI缓存实现
开发语言·qt·缓存
Antonio91510 小时前
【Redis】 Redis 基础命令和原理
数据库·redis·缓存
daixin88481 天前
什么是缓存雪崩?缓存击穿?缓存穿透?分别如何解决?什么是缓存预热?
java·开发语言·redis·缓存
daixin88481 天前
Redis过期数据的删除策略是什么?有哪些?
数据库·redis·缓存
EmpressBoost1 天前
谷粒商城170缓存序列化报错
java·spring·缓存
幻灭行度1 天前
通过redis_exporter监控redis cluster
数据库·redis·缓存