admin管理员组文章数量:1576972
输入URL,客户端到服务器通信全过程
按五层网络协议进行理解:
在主机上:
1、第五层——应用层:DNS解析
2、第四层——传输层:TCP三次握手、四次挥手
3、第三层——网络层:IP层
4、第2.5层——ARP地址解析协议(负责IP地址到MAC地址的解析)
5、第二层——数据链路层:MAC转发
6、第一层:物理层:把比特流转换为电信号
在路由器中进行转发:
1、解包目的MAC地址是否本路由,不是就丢弃
2、目的MAC是自己,解包,看目的IP是否是自己,是处理
3、目的IP不是自己,按路由表查询MAC地址
4、根据MAC表进行转发
到达服务器后:
解包,获取信息,通过三次握手于客户端建立TCP连接
备注:Http和Https的通信过程区别
DNS域名服务(应用层)
首先,客户端根据web域名,完成DNS解析
-
查询DNS缓存,看是否有记录;
-
查询本地hosts文件,看是否有记录;
-
查询本地DNS服务器,看是否有记录;
-
一路查询直到根域名服务器,根域名开始递归查询;
-
例如www.baidu,根域名服务器转到.域名服务器;
-
.域名服务器转到baidu.权威域名服务器;
-
baidu.域名服务器作为权威域名服务器,找到www的主机名,返回ip地址。
传输层(TCP)
三次握手
-
TCP客户端发送SYN=1,seq=x的同步包给服务器;
-
服务器收到后,发送SYN=1,ACK=1,seq=y,ack=x+1;
-
客户端收到后,发送ACK=1,seq=x+1,ack=y+1;
-
可以两次握手,第3次握手时,客户端可以发送想要发的数据
-
三次握手中,第一次服务器确定自己可以收,第二次客户端确定自己收发正常,第三次服务器确定自己发正常
-
如果没有第三次握手,服务器无法确认客户端是否建立连接,比如客户端此时撤销连接,但服务器却一直保持连接,就会造成服务器资源浪费
-
四次挥手
-
TCP客户端发送FIN=1,seq=x的包给服务器;
-
服务器收到后,发送ACK=1,seq=y,akc=x+1的;
-
此时服务器继续发送未发送完的消息,或接受未接收完的消息,等到服务器完成工作,发送FIN=1,ACK=1,seq=w,ack=x+1;
-
客户端收到后,发送ACK=1,seq=x+1,ack=w+1,并等待2个MSL(最长报文段寿命)。
-
如果没有第4次握手,服务器直接关闭连接,不管客户端是否收到FIN包,那么假设客户端未收到FIN包,就会一直重发FIN包,而不断开连接
-
等待2个MSL是为了确保服务器收到客户端的ACK包,如果服务器未收到ACK包,那么会重传FIN+ACK包,客户端就能在2MSL时间内收到,并重发ACK包
-
可以三次挥手,存在延时确认机制允许服务器可以过一会在发送ACK包,(Windows延迟200ms),如果服务器没有数据再发送给客户端,那就可以和FIN包一起发送(2、3步一起)
-
重传机制
-
超时重传(RTO,Rrtransmission Timeout ):数据包丢失、确认应答丢失
-
RTT(Round-Trip Time):往返时延,表示网络中两个主机之间的通信一来一回的时间间隔
-
RTO略大于RTT,如果RTO源大于RTT,就会导致网络效率低,反之,会一直被认为超时并重传
-
超时重传的数据再次超时的话,RTO扩大两倍,两次都超时重传,说明网络差,不宜传输数据
-
-
快速重传(Fast Retansmit):
-
三次收到ack=x,就认为x丢失,于是重传x
-
比如1,2,3,4,5,服务器收到1,3,4,5,发送3次ack=2,客户端重传2,此时服务器返回ack=6(因为1,2,3,4,5都收到了)
-
滑动窗口
-
发送窗口
可用窗口大小=SND.WND-(SND.NXT-SND.UNA)
-
接收窗口
-
发送窗口中的可用窗口=发送窗口-已发送未确认的窗口大小
流量控制
-
发送方根据接收方的实际接受能力,来控制发送的数据量
-
当接受方的接受窗口为0时,会进行窗口关闭,并通过ACK包告知发送方,发送方会启动持续计时器,到时间就发送窗口探测报文,接收方给出自己当前窗口大小,如果还是0,发送方重复即使,一般是3次,三次后发送方发送rst包(reset)连接
-
糊涂窗口综合征:发送数据量很小的包,数据量小于IP头部+TCP头部40字节
-
接收方不发送小窗口大小给发送方
-
发送方避免发送小数据量的包
-
拥塞控制
-
拥塞窗口:发送方动态调节发送数据量大小
-
发送窗口=min(接收窗口,拥塞窗口)
-
当网络出现超时重传,就认为出现拥塞,拥塞窗口减小,没有拥塞,拥塞窗口增大
-
慢启动
-
窗口初始值为cwnd=1,门限为ssthresh
-
指数级增长:2,4,8。。
-
当窗口到达门限(cwnd=ssthresh),进入拥塞避免
-
-
拥塞避免(ssthresh默认一般为65535字节)
-
到达门限后,变为线性增长:+1,+1,+1。。
-
直到遇到拥塞,进入拥塞发生
-
-
拥塞发生:出现拥塞就会利用前面提到的两种重传机制
-
超时重传
-
门限变为拥塞窗口二分之一(ssthresh=cwnd/2)
-
拥塞窗口变为1(cwnd=1)
-
重新进入慢启动
-
-
快速重传(和快速恢复一起使用)
-
拥塞窗口和门限都变为当前拥塞窗口的二分之一(cwnd=ssthresh=old_cwnd/2)
-
进入快速恢复
-
-
-
快速恢复
-
拥塞窗口+3(cwnd=ssthressh+3):因为收到3个ACK包
-
也就是快恢复实际是从old_cwnd/2+3开始,因为达到ssthresh,所以直接进入拥塞避免
-
分包和粘包
-
分包:有MSS最大消息长度限制应用层数据大于MSS,就要分包
-
粘包:TCP为了提高网络利用率,用Nagle算法,当要发送的数据量很小,就延迟发送,和下一个包一起发送
网络层(IP)
-
封装IP数据包
2.5层——ARP地址解析协议
-
利用ARP协议,解析MAC地址
-
在ARP缓存表查找目的IP,找到MAC地址;
-
当目的IP地址对应的MAC地址未知时,发送ARP数据帧,把以太网目的MAC地址设为全00:00:00:00:00:00,数据链路层封装MAC帧,将目的MAC地址设置为FF:FF:FF:FF:FF:FF,从除了该端口的其他端口广播,通过网络中的路由器(也有ARP协议)
-
其他主机收到该广播帧,发现ARP的目的MAC地址不是自己,丢弃
-
直到找到以太网目的IP对应MAC地址的主机,该主机记录源IP和源MAC地址到ARP缓存表,并返回响应
-
客户端获得目的MAC地址(过程中其他没有该MAC地址的路由器也要记录该IP和MAC地址)
-
数据链路层(MAC)
-
ARP地址解析得到目的MAC后
-
根据MAC地址表查找对应接口,找到目的MAC地址对应接口,进行转发
-
未找到目的MAC地址对应接口,目的MAC设为FF:FF:FF:FF:FF:FF,从其他所有接口进行广播
路由器(MAC帧离开客户端在网络中进行传输)
路由器集成交换机的功能
-
首先路由器拿到MAC帧,去掉头部8个字节(前同步码和真开始界定符),检查尾部FCS,不正确,丢弃该帧
-
目的MAC地址不是自己,丢弃
-
是自己,拆开,到IP包
-
目的IP是自己,接收
-
把源IP和子网掩码,接口或上一跳IP进行记录进路由表(表示到达上一个路由器的路由信息)
-
目的IP不是自己,查找路由表(目的IP与路由表中的子网掩码做and,看所得网络号是否有记录)
-
一条一条查找,找到网络号,从相对应的接口或者下一跳ip地址进行转发
-
没有找到,从记录的默认路由的端口或吓一跳IP地址进行转发(默认路由IP 0.0.0.0,子网掩码 0.0.0.0)
-
封装为MAC帧,目的MAC根据ARP协议找到下一跳路由器的MAC地址,并进行转发
-
直到到达目的MAC地址(也就是服务器)
-
物理层
-
把MAC帧变成二进制比特流,并转换为电信号, 在物理链路传输
Http和Https
Http过程
-
DNS解析域名,得到IP
-
ARP协议解析目的MAC地址
-
客户端与服务器三次握手建立TCP连接
-
客户端发送Http请求,服务器返回响应
-
客户端接受响应,在浏览器进行渲染
-
四次挥手终止TCP连接
Https通信过程(443端口)
-
SSL用来数字签名和认证,并产生对称密钥K
-
TSL利用对称密钥K进行数据传输
-
DNS解析域名,得到IP
-
ARP协议解析目的MAC地址
-
客户端与服务器三次握手建立TCP连接
-
客户端在TCP第三次握手或者重新发送给服务器的报文中,包含自己支持的SSL加密算法,TSL/SSL版本等列表和第一个随机数R1
-
服务器会在之前,向CA数字认证中心申请证书,CA用自己的私钥加密,并发送给服务器
-
服务器返回响应,报文包含选中的SSL加密算法,第二个随机数R2
-
服务器再次发送给客户端两个报文,一个包含自己的证书信息,一个包含自己的公钥(如果需要客户端的证书,也包含在第二个报文中,在网银登录时需要)
-
客户端通过CA的公钥验证证书的数字签名,通过就信任服务器
-
客户端生成第三个随机数R3,并利用R1,R2,R3生成对称密钥K这个K用于TSL协议)
-
用服务器的公钥加密第三个随机数R3(预主密钥),并发送给服务器
-
服务器用私钥解密R3,并利用R1,R2,R3,以和客户端同样的算法生成对称密钥K(这个K用于TSL协议)
-
客户端和服务器通过密钥K利用TSL协议进行数据传输
-
四次挥手
Get和Post
-
并非所有浏览器在POST中会发送两次TCP包,FireFox就只有一次
Get | Post |
---|---|
一个TCP数据包,浏览器把Http的header和data一起发送出去,因为不涉及body | 产生两个TCP数据包,浏览器先发送header,服务器响应100 continue,浏览器发送body,服务器响应200 OK |
参数在URL中 | 参数在body中 |
URL可见,如果用于传递用户名密码不安全,且能被浏览器缓存,查询历史纪录可查到 | 参数在body中,用户不可见,不能保存书签,查询历史纪录看不到 |
URL长度收到浏览器服务器限制 | body长度理论上无限制,可以更长 |
URL支持部分ASCII编码,比如不支持空格,需要被替换为%20等,对中文的支持可能乱码 | 支持多种编码,可以支持中文 |
会被浏览器缓存,可以保存为书签 | 不能保存为书签 |
用在服务器上获取数据 | 向服务器提交表单数据 |
状态码 | 描述 |
---|---|
1XX | 提示信息,请求已接收,继续处理 |
2XX | 成功 |
3XX | 重定向 |
4XX | 客户端错误(语法错误或请求无法实现) |
5XX | 服务器错误(服务器不能返回响应) |
200 | OK |
204 | 请求被处理但没有资源可以返回 |
301 | 永久重定向(返回301,加新地址 ,浏览器显示就地址,但加载新地址的资源) |
302 | 临时重定向 |
400 | 语法错误,服务器无法识别 |
401 | 未认证 |
403 | 请求的资源禁止访问 |
404 | 服务器找不到资源 |
405 | 方法不被允许 |
500 | 服务器内部错误 |
503 | 服务器正忙,无法处理请求 |
504 | 网关超时 |
Http优化
-
TCP复用(Http1.1支持):把多个Http请求复用到一个Http连接上
-
Http复用(负载均衡设备支持):一个客户端的多个Http请求通过一个TCP连接处理,客户端连接负载均衡设备,负载均衡设备与服务器连接,放客户端完成一次Http请求,断开与负载均衡设备连接,但负载均衡折别与服务器保持连接,下一次客户端在于负载均衡设备建立连接即可,使得服务器不用一直断开,节约资源
可断开
一直保持
客户端浏览器
负载均衡设备
服务器1
-
内容缓存:常用内容且无需经常更新,缓存到浏览器
-
压缩:将文本数据压缩
Http和Websocket
-
Http中,客户端主动,服务器被动,有长连接和短连接:
-
长连接一段时间保持TCP连接
-
短连接每次发送一次请求获得响应都要建立TCP握手三次
-
-
Websocket客户端服务器双工:
-
服务器可以在没有请求的情况下向客户端发送消息
-
服务器和客户端交换的header很小,可以节约资源
-
-
Http长连接每次都要发送header,Websocket只需要一个request和response
Cookie和Session、JWT
Cookie
-
会话跟踪技术,服务器生成,保存在浏览器本地,存储键值对,默认浏览器关闭过期
-
客户端与服务器建立TCP连接,第一次请求时,服务器生成cookie,(可以选择时/否保存在服务器),发送给浏览器
-
浏览器每次发送请求都带上cookie信息
-
应用场景:
-
保持登录状态
-
获取用户名,在浏览器显示
-
Session
-
服务器会话跟踪技术,服务器生成,保存在服务器,存储键值对,默认两周过期
-
依赖cookie,唯一标识码session id存储在cookie中
-
base64加密
-
应用场景:
-
安全性比较高的数据,银行卡账户密码等
-
也可以保持登录:sessionid给用户,用户保存cookie到本地,下次在启动浏览器,发送这个cookie中的sessionid个i服务器,服务器调出session信息即可
-
-
实现方法:
-
浏览器不禁止cookie,且保存cookie
-
浏览器禁止cookie,保存sessionid后,提出sessionid但是通过url或者提交表单隐藏字段的方式
-
JWT(Json Web Token)
-
组成:
-
Header:通常包含两个字段
{ "alg": "HS256" # 默认HMacSha256 "typ": "JWT" # 默认JWT }
-
Playload:一个json字符串,包含用户信息、过期时间等
{ # 公有声明 "exp": xxx # 过期时间 "iss":xxx, # (issuer) 指明此token的签发者 "aud":xxx, # (Audience) 指明此token的签发群体 "iat":xxx, # (ISSued At) 指明此创建时间的时间戳 # 私有声明 "username": "aaa" # 不能包含用户密码等,因为可以被base64解码 }
-
Signature:签名
HMACSHA256(base64.b64encode(Header.encode())+'.'.encode()+base64.b64encode(Playload.encode()),Secret_key)
-
-
JWT认证过程
-
客户端通过POST表单提交用户名、密码
-
服务器验证成功,将用户id和其他信息作为JWT Playload(负载),与JWT Header分别进行base64编码后,进行签名,生成一个JWT字符串xxx.yyy.zzz(三部分)token,返回给客户端,在Playload中有过期时间
-
客户端保存token,并设置有效期(建议和服务器一致),可以保存在cookie,也可以保存在内存(移动端没有cookie或者浏览器不允许cookie时)
-
客户端每次发送请求给服务器,都会把这个token放在Http或Https的header的Authorization位置
-
服务器检查token是否是发给自己的,是否在有效期,签名是否正确,都满足条件,返回正常响应,否则,返回登陆错误并跳转到登录页面
-
token有效期:有效期有服务器设置,有效期更新:
-
浏览器每次发送请求,服务器都重新生成token
-
服务器检查token,小于阈值(还没过期),就重新生成
-
session | JWT |
---|---|
保存在服务器 | 保存在客户端 |
如果session包含许多信息,增加服务器存储压力 | 签名的计算和验证花费服务器计算时间 |
区别
cookie | session | JWT |
---|---|---|
客户端 | 服务器中 | 客户端 |
不安全,可以分析本地cookie | 在服务器中,比较安全,且用base64加密 | 有签名技术,防止篡改 |
客户端本地存储,不安全 | 依赖cookie,唯一标识session ID在cookie中,有存储压力 | 不依赖cookie和session,服务器只需要计算签名正确性,没有存储压力 |
默认浏览器关闭过期 | 默认两周过期 | 有设置的过期时间 |
版权声明:本文标题:输入URL,客户端到服务器通信的过程 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/xitong/1727807597a1131151.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论