输入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解析

  1. 查询DNS缓存,看是否有记录;

  2. 查询本地hosts文件,看是否有记录;

  3. 查询本地DNS服务器,看是否有记录;

  4. 一路查询直到根域名服务器,根域名开始递归查询;

  5. 例如www.baidu.com,根域名服务器转到.com.域名服务器;

  6. .com.域名服务器转到baidu.com.权威域名服务器;

  7. baidu.com.域名服务器作为权威域名服务器,找到www的主机名,返回ip地址。

传输层(TCP)

三次握手

  1. TCP客户端发送SYN=1,seq=x的同步包给服务器;

  2. 服务器收到后,发送SYN=1,ACK=1,seq=y,ack=x+1;

  3. 客户端收到后,发送ACK=1,seq=x+1,ack=y+1;

    • 可以两次握手,第3次握手时,客户端可以发送想要发的数据

    • 三次握手中,第一次服务器确定自己可以收,第二次客户端确定自己收发正常,第三次服务器确定自己发正常

    • 如果没有第三次握手,服务器无法确认客户端是否建立连接,比如客户端此时撤销连接,但服务器却一直保持连接,就会造成服务器资源浪费

四次挥手

  1. TCP客户端发送FIN=1,seq=x的包给服务器;

  2. 服务器收到后,发送ACK=1,seq=y,akc=x+1的;

  3. 此时服务器继续发送未发送完的消息,或接受未接收完的消息,等到服务器完成工作,发送FIN=1,ACK=1,seq=w,ack=x+1;

  4. 客户端收到后,发送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(接收窗口,拥塞窗口)

  • 当网络出现超时重传,就认为出现拥塞,拥塞窗口减小,没有拥塞,拥塞窗口增大

  1. 慢启动

    • 窗口初始值为cwnd=1,门限为ssthresh

    • 指数级增长:2,4,8。。

    • 当窗口到达门限(cwnd=ssthresh),进入拥塞避免

  2. 拥塞避免(ssthresh默认一般为65535字节)

    • 到达门限后,变为线性增长:+1,+1,+1。。

    • 直到遇到拥塞,进入拥塞发生

  3. 拥塞发生:出现拥塞就会利用前面提到的两种重传机制

    • 超时重传

      • 门限变为拥塞窗口二分之一(ssthresh=cwnd/2)

      • 拥塞窗口变为1(cwnd=1)

      • 重新进入慢启动

    • 快速重传(和快速恢复一起使用)

      • 拥塞窗口和门限都变为当前拥塞窗口的二分之一(cwnd=ssthresh=old_cwnd/2)

      • 进入快速恢复

  4. 快速恢复

    • 拥塞窗口+3(cwnd=ssthressh+3):因为收到3个ACK包

    • 也就是快恢复实际是从old_cwnd/2+3开始,因为达到ssthresh,所以直接进入拥塞避免

分包和粘包

  • 分包:有MSS最大消息长度限制应用层数据大于MSS,就要分包

  • 粘包:TCP为了提高网络利用率,用Nagle算法,当要发送的数据量很小,就延迟发送,和下一个包一起发送

网络层(IP)

  • 封装IP数据包

2.5层——ARP地址解析协议

  • 利用ARP协议,解析MAC地址

    1. 在ARP缓存表查找目的IP,找到MAC地址;

    2. 当目的IP地址对应的MAC地址未知时,发送ARP数据帧,把以太网目的MAC地址设为全00:00:00:00:00:00,数据链路层封装MAC帧,将目的MAC地址设置为FF:FF:FF:FF:FF:FF,从除了该端口的其他端口广播,通过网络中的路由器(也有ARP协议)

    3. 其他主机收到该广播帧,发现ARP的目的MAC地址不是自己,丢弃

    4. 直到找到以太网目的IP对应MAC地址的主机,该主机记录源IP和源MAC地址到ARP缓存表,并返回响应

    5. 客户端获得目的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,看所得网络号是否有记录)

    1. 一条一条查找,找到网络号,从相对应的接口或者下一跳ip地址进行转发

    2. 没有找到,从记录的默认路由的端口或吓一跳IP地址进行转发(默认路由IP 0.0.0.0,子网掩码 0.0.0.0)

    3. 封装为MAC帧,目的MAC根据ARP协议找到下一跳路由器的MAC地址,并进行转发

    4. 直到到达目的MAC地址(也就是服务器)

物理层

  • 把MAC帧变成二进制比特流,并转换为电信号, 在物理链路传输

Http和Https

Http过程

  1. DNS解析域名,得到IP

  2. ARP协议解析目的MAC地址

  3. 客户端与服务器三次握手建立TCP连接

  4. 客户端发送Http请求,服务器返回响应

  5. 客户端接受响应,在浏览器进行渲染

  6. 四次挥手终止TCP连接

Https通信过程(443端口)

  • SSL用来数字签名和认证,并产生对称密钥K

  • TSL利用对称密钥K进行数据传输

  1. DNS解析域名,得到IP

  2. ARP协议解析目的MAC地址

  3. 客户端与服务器三次握手建立TCP连接

  4. 客户端在TCP第三次握手或者重新发送给服务器的报文中,包含自己支持的SSL加密算法,TSL/SSL版本等列表和第一个随机数R1

  5. 服务器会在之前,向CA数字认证中心申请证书,CA用自己的私钥加密,并发送给服务器

  6. 服务器返回响应,报文包含选中的SSL加密算法,第二个随机数R2

  7. 服务器再次发送给客户端两个报文,一个包含自己的证书信息,一个包含自己的公钥(如果需要客户端的证书,也包含在第二个报文中,在网银登录时需要)

  8. 客户端通过CA的公钥验证证书的数字签名,通过就信任服务器

  9. 客户端生成第三个随机数R3,并利用R1,R2,R3生成对称密钥K这个K用于TSL协议)

  10. 用服务器的公钥加密第三个随机数R3(预主密钥),并发送给服务器

  11. 服务器用私钥解密R3,并利用R1,R2,R3,以和客户端同样的算法生成对称密钥K(这个K用于TSL协议)

  12. 客户端和服务器通过密钥K利用TSL协议进行数据传输

  13. 四次挥手

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优化

  1. TCP复用(Http1.1支持):把多个Http请求复用到一个Http连接上

  2. Http复用(负载均衡设备支持):一个客户端的多个Http请求通过一个TCP连接处理,客户端连接负载均衡设备,负载均衡设备与服务器连接,放客户端完成一次Http请求,断开与负载均衡设备连接,但负载均衡折别与服务器保持连接,下一次客户端在于负载均衡设备建立连接即可,使得服务器不用一直断开,节约资源

    
    

    可断开

    一直保持

    客户端浏览器

    负载均衡设备

    服务器1

  3. 内容缓存:常用内容且无需经常更新,缓存到浏览器

  4. 压缩:将文本数据压缩

Http和Websocket

  • Http中,客户端主动,服务器被动,有长连接和短连接:

    • 长连接一段时间保持TCP连接

    • 短连接每次发送一次请求获得响应都要建立TCP握手三次

  • Websocket客户端服务器双工:

    • 服务器可以在没有请求的情况下向客户端发送消息

    • 服务器和客户端交换的header很小,可以节约资源

  • Http长连接每次都要发送header,Websocket只需要一个request和response

Cookie和Session、JWT

Cookie

  • 会话跟踪技术,服务器生成,保存在浏览器本地,存储键值对,默认浏览器关闭过期

  1. 客户端与服务器建立TCP连接,第一次请求时,服务器生成cookie,(可以选择时/否保存在服务器),发送给浏览器

  2. 浏览器每次发送请求都带上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认证过程

  1. 客户端通过POST表单提交用户名、密码

  2. 服务器验证成功,将用户id和其他信息作为JWT Playload(负载),与JWT Header分别进行base64编码后,进行签名,生成一个JWT字符串xxx.yyy.zzz(三部分)token,返回给客户端,在Playload中有过期时间

  3. 客户端保存token,并设置有效期(建议和服务器一致),可以保存在cookie,也可以保存在内存(移动端没有cookie或者浏览器不允许cookie时)

  4. 客户端每次发送请求给服务器,都会把这个token放在Http或Https的header的Authorization位置

  5. 服务器检查token是否是发给自己的,是否在有效期,签名是否正确,都满足条件,返回正常响应,否则,返回登陆错误并跳转到登录页面

  • token有效期:有效期有服务器设置,有效期更新:

    • 浏览器每次发送请求,服务器都重新生成token

    • 服务器检查token,小于阈值(还没过期),就重新生成

session JWT
保存在服务器 保存在客户端
如果session包含许多信息,增加服务器存储压力 签名的计算和验证花费服务器计算时间

区别

cookie session JWT
客户端 服务器中 客户端
不安全,可以分析本地cookie 在服务器中,比较安全,且用base64加密 有签名技术,防止篡改
客户端本地存储,不安全 依赖cookie,唯一标识session ID在cookie中,有存储压力 不依赖cookie和session,服务器只需要计算签名正确性,没有存储压力
默认浏览器关闭过期 默认两周过期 有设置的过期时间

输入URL,客户端到服务器通信的过程相关推荐

  1. Websocket(二)-客户端与服务器通信

    Websocket(二)-客户端与服务器通信 服务端 客户端测试 const WebSocket = require('ws'); const Server = WebSocket.Server; c ...

  2. Exchange邮件系统客户端与服务器通信常用网络端口

    Exchange邮件系统:客户端与服务器通信常用网络端口 序号 用途 端口 1 未加密的web连接: •互联网日历发布 •Outlook on the web(重定向到443/TCP) •自动发现(4 ...

  3. 试简述smtp通信的三个阶段的过程_从输入URL到页面加载的过程?《转载》

    这是我看过这个问题最完整/优质的回答了,转来分享 知乎的排版不太好,可以浏览博客原文: http://gaoxiang.ga/index.php/archives/36/​gaoxiang.ga 前言 ...

  4. 输入URL到浏览器显示页面的过程,搜集各方面资料总结一下

    面试中经常会被问到这个问题吧,唉,我最开始被问到的时候也就能大概说一些流程.被问得多了,自己就想去找找这个问题的全面回答,于是乎搜了很多资料和网上的文章,根据那些文章写一个总结. 写得不好,或者有意见 ...

  5. layui 如何动态加载局部页面_从输入URL到页面加载的过程?如何由一道题完善自己的前端知识体系!

    前言 见解有限,如有描述不当之处,请帮忙指出,如有错误,会及时修正. 为什么要梳理这篇文章? 最近恰好被问到这方面的问题,尝试整理后发现,这道题的覆盖面可以非常广,很适合作为一道承载知识体系的题目. ...

  6. 从输入URL到页面加载的过程?由一道题完善自己的前端知识体系!

    梳理主干流程 这道题上,如何回答呢?先梳理一个骨架. 知识体系中,最重要的是骨架,脉络.有了骨架后,才方便填充细节.所以,先梳理下主干流程: 从浏览器接收url到开启网络请求线程(这一部分可以展开浏览 ...

  7. layui 如何动态加载局部页面_从输入URL到页面加载的过程?如何由一道题完善自己的前端知识体系!...

    作者:撒网要见鱼 原文链接:http://www.dailichun.com/2018/03/12/whenyouenteraurl.html 「----超长文预警,需要花费大量时间.----」 本文 ...

  8. 从输入URL到页面加载的过程?如何由一道题完善自己的前端知识体系!

    前言 见解有限,如有描述不当之处,请帮忙指出,如有错误,会及时修正. 为什么要梳理这篇文章? 最近恰好被问到这方面的问题,尝试整理后发现,这道题的覆盖面可以非常广,很适合作为一道承载知识体系的题目. ...

  9. 从输入URL到页面加载的过程

    1.主干流程知识体系? 1. 从浏览器接收url到开启网络请求线程(这一部分可以展开浏览器的机制以及进程与线程之间的关系)2. 开启网络线程到发出一个完整的http请求(这一部分涉及到dns查询,tc ...

最新文章

  1. Layui Excle/csv数据导出
  2. 编程面试中的十个常见错误
  3. MemSQL初体验 - (2)初始化测试环境
  4. (转载)ubuntu开启SSH服务
  5. bat执行时,跳转到当前bat文件所在盘符的根目录下面
  6. (二十六)深度学习目标检测:Fast-RCNN
  7. jar k8s 自己的 部署_怎样部署K8S服务器
  8. sublime Text 2使用小技巧
  9. 用户体验五要素_用户体验五要素—结构性思考
  10. 一个元素的偏移的方法
  11. 用例图分析---学生成绩管理系统
  12. 数据结构C语言般卷纸真题,数据结构(C语言版)考研真题(A卷)
  13. Flink Forward Asia Hackathon (2021) 回顾
  14. 淘宝PC自动化测试框架AutomanX-王超
  15. vue3 setup语法糖与原始写法对比
  16. 小型企业Azure云迁移大型指南
  17. Elasticsearch 学习(二).实战使用
  18. 5:Echarts数据可视化-多条曲线、多个子图、TreeMap类似盒图、树形图、热力图、词云...
  19. ES6 碎片化知识积累
  20. 刚子扯谈:我对黑客精神的一些认知

热门文章

  1. 浏览器原理-v8引擎-js执行原理
  2. 应用BERT模型做命名实体识别任务
  3. styl类型文件css,Stylus: 让你更简洁的完成css
  4. 旺旺老师JavaSE基础第一章(03)JDK下载和安装
  5. (附源码)spring boot学业指导系统 毕业设计 030958
  6. 软件测试肖sir__007用例编写技巧
  7. 7-8 估值一亿的AI核心代码 (20 分) 代码有解析
  8. 婚礼邀请函 - 婚柬 - 微信小程序 - 小程序端
  9. 离散数学,生成元,元素的阶
  10. python定义一个复数类_Python中complex复数类型的简单介绍