一次HTTP请求的背后

本文涉及的产品
数据传输服务 DTS,数据同步 small 3个月
推荐场景:
数据库上云
数据传输服务 DTS,数据迁移 small 3个月
推荐场景:
MySQL数据库上云
云解析 DNS,旗舰版 1个月
简介: 基础概念网络七层模型应用层提供网络管理、文件传输、事务处理,Telnet、FTP、HTTP、SNMP、DNS,HTTPS.在这里稍微解释下.HTTPhttp0.9 是http协议的第一个版本,只有普通的get请求.http1.0,引入post请求,让HTML的表单可以提交表单.引入加入请求头Header ,让既一次TCP连接后,可以多次通信,虽然HTTP1.0 默认是传输一次数据后就关闭。

基础概念


网络七层模型

应用层

提供网络管理、文件传输、事务处理,Telnet、FTP、HTTP、SNMP、DNS,HTTPS.在这里稍微解释下.

HTTP

  • http0.9 是http协议的第一个版本,只有普通的get请求.

  • http1.0,引入post请求,让HTML的表单可以提交表单.引入加入请求头Header ,让
    既一次TCP连接后,可以多次通信,虽然HTTP1.0 默认是传输一次数据后就关闭。

  • http1.1,加入keep alive等.

HTTPS:加密数据传输

发起请求:通过443端口发起https请求
关于HTTPS,这里有一篇不错的文章[传送门]

宿主host:
(主机名) 加快域名解析,当进行DNS请求时,系统会自动检查host文件是否有这个网络域名映射关系。如果有则,调用这个IP地址映射,如果没有,再向已知的DNS服务器提出域名解析。也就是说Hosts的请求级别比DNS高。
**DNS(Domain Name System) **
域名解析器,将域名和ip绑定

表示层

不同数据编码格式的转换,提供数据压缩、解压缩服务,对数据进行加密、解密。例如图像格式的显示

会话层

将数据组合成数据Data,建立和维持对话.

传输层

将数据组合成段Segment,用tcp,udp等进行数据传输.

网络层

分割和重新组合数据包Packet,基于网络层地址IP,进行路径选择.例如路由器.

当前TCP/IP协议族:

  • IPv4的地址位数是32位,也就是说最多有2^32台电脑可以连接到互联网.

  • IPv6采用128位地址长度,也就是2^128台电脑可以连接.几乎可以不受限制地提供地址.除此之外,还改善了IPv4中解决不好的问题,主要有端到端IP连接、服务质量(QoS)、安全性、多播、移动性、即插即用等

  • ARP(Address Resolution Protocol) 地址解析协议(在IPv4)

数据链接层

在物理层上建立可靠的传输,单位是Frame.功能是:物理地址寻址,数据成帧,流量控制,数据监测等.例如网桥,交换机.
协议包括:SDLC(sychronous Date Line Control),HDLC,PPP(Point-to-Point),STP等

物理层

是数据传递的实体,数据传输单位是bit,例如光纤,电缆等.


在介绍TCP之前,先说一下UDP和TCP的区别

  • UDP传输就类似于写信,接收方事先并不知道你要写信给他;
    即无法判断在传输过程中,会不会发生丢包,阻塞,等情况.

  • TCP传输就像是打电话,必须等对方按了接听键你才能更他通话。
    TCP报文有自己的检测机制,检验、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输.

TCP协议的特点

TCP协议是一种面向连接的,基于字节流的传输层协议.TCP将用户数据打成报文段(如下报文图),在发送的时候启动一个定时器,在另外一端接受的时候,对数据会进行确认,排序,去重复(根据序列号,确认号比较进行确认)等操作.应用层的http,是使用TCP建立连接的.

如果想要充分读懂TCP是如何收发包,以及序列号的,请点击[传送门]

TCP报文首部:

img_cab30d8877d35bd31d0c1adfd03af845.jpe

  1. 源端口号:数据发起者的端口号,16bit

  2. 目的端口号:数据接收者的端口号,16bit

  3. 序号:32bit的序列号,由发送方使用,根据发送的字节数据变化

  4. 确认序号32bit的确认号,是接收数据方期望收到发送方的下一个报文段的序号,因此确认序号应当是上次已成功收到数据字节序号加1。

  5. 首部长度:首部中32bit字的数目,可表示15*32bit=60字节的首部。一般首部长度为20字节。

  6. 保留:6bit, 均为0

  7. 紧急URG:当URG=1时,表示报文段中有紧急数据,应尽快传送。

  8. 确认比特ACK:ACK = 1时代表这是一个确认的TCP包,取值0则不是确认包。

  9. 推送比特PSH:当发送端PSH=1时,接收端尽快的交付给应用进程。

  10. 复位比特(RST):当RST=1时,表明TCP连接中出现严重差错,必须释放连接,再重新建立连接。

  11. 同步比特SYN:在建立连接是用来同步序号。SYN=1, ACK=0表示一个连接请求报文段。SYN=1,ACK=1表示同意建立连接。

  12. 终止比特FIN:FIN=1时,表明此报文段的发送端的数据已经发送完毕,并要求释放传输连接。

  13. 窗口:用来控制对方发送的数据量,通知发放已确定的发送窗口上限。

  14. 检验和:该字段检验的范围包括首部和数据这两部分。由发端计算和存储,并由收端进行验证。

  15. 紧急指针:紧急指针在URG=1时才有效,它指出本报文段中的紧急数据的字节数。

  16. 选项:长度可变,最长可达40字节


HTTP请求流程

时间线流程

img_4bb4151468c31ae23ffd02c492a2070b.jpe
这里写图片描述

网络层级关系

img_fd5af48080fb5489521aa1f3516f42c8.png

请求流程分析

解析域名(HOST/DNS)

  • 一个域名 会首先访问本地的Host文件,查看有没有域名对应的访问ip的映射
  • 如果有,就直接得到IP,如果没有,就通过DNS根服务器,
  • DNS根服务器会询问.net域名服务器,有没有此域名
  • net域名服务器会查找blog.csdn.net是否存在
  • 如果存在,就返回相应的IP地址
  • ARP协议解析ip对应的物理地址,并加入到ARP缓存
  • 进行TCP握手

三次握手

相互请求,相互确认的过程.

就像长途运货车
你和总部说,我想运货,
然后总部收到你的短信,给你回信说:恩,收到,去吧
你说,收到,马上去.

在此先设定

SYN1表示客户端的同步信号,ACK1表示客户端的确认信号,FIN1表示客户端对服务器信道停止信号

SYN2表示服务器的同步信号,ACK2表示服务器的确认信号,FIN2表示服务器对客户端信道停止信号

SYN根据ACK的相应而变化.使用确认号1响应服务端的序列号0

序列号代表发送的数据编号,确认序列代表收到的数据编号.

序列号和确认序列在握手的时候发送的时候都会自动+1(说的不太恰当);

序列号为当前端成功发送的数据位数,确认号为当前端成功接收的数据位数,SYN标志位和FIN标志位也要占1位

第一次:

客户端发起请求(发送SYN1=1,ACK1=0)到服务器,此时,服务器进入'SYN_SENT'(客户端已经提交SYN报文)状态,等待服务器响应.

第二次:

服务器收到SYN包,确认客户端的SYN包而生成ACK(ACK=j+1)包,还有自己的一个请求编号SYN
(SYN=k), 即发送SYN+ACK包(发送SYN2=0,ACK2=1)到客户端.此时,服务器进入'SYN_RECV'状态.

第三次:

客户端收到服务器的SYN+ACK包,然后,自己向服务器发送确认包ACK(发送SYN1=0+1,ACK1=0+1=1),此时,服务器进入'ESTABLISHED'(链接成功)状态,完成三次握手
(连接完成状态表示为SYN1=1,ACK1=1,SYN2=1,ACK2=1).

img_1a76bb364c3e1380c36c68946ae49d10.jpe

数据传输过程

第四次(客户端请求服务器发出的有效数据包)

这是流中第一个携带有效数据的包(确切的说,是客户端发送的HTTP请求),序列号依然为1,因为到上个包为止,还没有发送任何数据,确认号也保持1不变,因为客户端没有从服务端接收到任何数据

需要注意的是,包中有效数据的长度为125字节,但是一共有125+1个数据,因为序列号也占用字节.

服务端的序列号为1.确认号为1,TCP客户端的序列号为126.确认号为1

第五次(服务器得到包,并处理得到的数据)

当上层处理HTTP请求时,服务端发送该包来确认客户端在包4中发来的数据,需要注意的是,确认号的值增加了125(125是包4中有效数据长度),变为126,
服务端以此来告知客户端端,目前为止,我总共收到了126字节的数据,服务端的序列号保持为1不变

服务端的序列号为1.确认号为126,TCP客户端的序列号仍为126.确认号为1

第六次(服务器发出数据包)

这个包标志着服务端返回HTTP响应的开始,序列号依然为1,因为服务端在该包之前返回的包中都不带有有效数据,该包带有512字节的有效数据.

服务端的序列号为513.确认号为126,TCP客户端的序列号仍为126.确认号为1

第七次(客户端接受数据包)

客户端接收到数据.到此为止,一次tcp的短连接,一次网络请求完成().
当tcp进行长链接的时候,会不断地相互增长.
服务端的序列号为513.确认号为126,TCP客户端的序列号仍为126.确认号为1+513=514

连接终止协议(四次挥手)

第一次:

TCP的客户端发送一个FIN(FIN=1),用来关闭客户到服务器的数据传输.

此时,将标志位FIN1=1.

服务端的序列号为513.确认号为126,TCP客户端的序列号仍为126+1.确认号为514

第二次:

服务器收到这个FIN,它发出一个ACK2=1,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号。

此时,FIN1=1,ACK2=1,通道1关闭,服务器确定

服务端的序列号为513.确认号为126+1=127,TCP客户端的序列号仍为126.确认号为514

第三次:

服务器关闭客户端连接,发一个FIN2=1的标志位给客户端,

此时,将标志位FIN1=1,FIN2=1.ACK2=1,通道1,2关闭,服务器确定

服务端的序列号为513.确认号为126+1=127,TCP客户端的序列号仍为126.确认号为514

第四次:

客户端发回ACK1=1报文确认,并将确认序号设置为收到序号加1。

此时,FIN1=1,ACK2=1,ACK1=1,ACK2=1,通道1,2关闭,客户端确认,服务端确认.连接关闭

服务端的序列号为513.确认号为126+1+1=128,TCP客户端的序列号为126+1=127(最终序列号).确认号为514

img_30f5c68115747c80e3cc119128df5bc4.jpe

附软件截图

img_9dcae89ce176f0625f89eb2c30f07169.png
img_20ca3fb92f2e9b30d627692012d80ae1.png

总结

1.正常网络连接的实质都是TCP连接下的bit流的传输(没有考虑UDP等).

2.一个网络请求,过程复杂,需要跨过网关,解析域名,TCP握手,各种缓存策略,协议和报文等机制复杂.

3.HTTP协议,所有信息都是公开的,容易被第三方获取.HTTPS运用了SSL加密,对称,非对称,hash加密等.

4.三次握手的意义在于,双方都进行了确认后再代开连接,防止已经链接失效,或者因为网络延时造成的重复分组.造成建立新的tcp链接,造成service一直等待,浪费资源.

5.四次挥手的原因是,TCP是全双工,因此每个方向都必须单独关闭.收到一个FIN,代表这个信道,在此之后不会传输数据.但是一个TCP连接在发出FIN之前,收到一个FIN后仍能发送数据.

6.协议在不断地更新换代,效率越来越高!

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
20天前
|
Rust 前端开发 API
Tauri 开发实践 — Tauri HTTP 请求开发
本文介绍了如何在 Tauri 中发起 HTTP 请求。首先通过安装 Tauri 生态中的工具包并配置 `tauri.conf.json` 文件来允许特定域名的 HTTP 通信。接着封装了一个简单的 HTTP 客户端类,并在页面中使用该客户端实现 GET 和 POST 请求。最后提供了完整的源码地址以供参考。此功能使得桌面应用能够与远程服务器进行交互,增强了应用的实用性。
53 1
Tauri 开发实践 — Tauri HTTP 请求开发
|
5天前
|
数据采集 前端开发 算法
Python Requests 的高级使用技巧:应对复杂 HTTP 请求场景
本文介绍了如何使用 Python 的 `requests` 库应对复杂的 HTTP 请求场景,包括 Spider Trap(蜘蛛陷阱)、SESSION 访问限制和请求频率限制。通过代理、CSS 类链接数控制、多账号切换和限流算法等技术手段,提高爬虫的稳定性和效率,增强在反爬虫环境中的生存能力。文中提供了详细的代码示例,帮助读者掌握这些高级用法。
Python Requests 的高级使用技巧:应对复杂 HTTP 请求场景
|
6天前
|
网络协议
Lua中实现异步HTTP请求的方法
Lua中实现异步HTTP请求的方法
|
4天前
|
存储 安全 网络协议
HTTP 请求方法
【10月更文挑战第22天】HTTP 请求方法
6 2
|
4天前
|
缓存 JSON 安全
HTTP请求发送方法
HTTP请求发送方法【10月更文挑战第22天】
8 2
|
24天前
|
缓存 网络协议 JavaScript
【HTTP】构造HTTP请求和状态码
【HTTP】构造HTTP请求和状态码
42 1
【HTTP】构造HTTP请求和状态码
|
24天前
|
存储 Java 程序员
【HTTP】请求“报头”,Referer 和 Cookie
【HTTP】请求“报头”,Referer 和 Cookie
32 1
【HTTP】请求“报头”,Referer 和 Cookie
|
2月前
|
监控 网络协议 应用服务中间件
【Tomcat源码分析】从零开始理解 HTTP 请求处理 (第一篇)
本文详细解析了Tomcat架构中复杂的`Connector`组件。作为客户端与服务器间沟通的桥梁,`Connector`负责接收请求、封装为`Request`和`Response`对象,并传递给`Container`处理。文章通过四个关键问题逐步剖析了`Connector`的工作原理,并深入探讨了其构造方法、`init()`与`start()`方法。通过分析`ProtocolHandler`、`Endpoint`等核心组件,揭示了`Connector`初始化及启动的全过程。本文适合希望深入了解Tomcat内部机制的读者。欢迎关注并点赞,持续更新中。如有问题,可搜索【码上遇见你】交流。
【Tomcat源码分析】从零开始理解 HTTP 请求处理 (第一篇)
|
21天前
|
存储 JSON API
HTTP 请求与响应处理:C#中的实践
【10月更文挑战第4天】在现代Web开发中,HTTP协议至关重要,无论构建Web应用还是API开发,都需要熟练掌握HTTP请求与响应处理。本文从C#角度出发,介绍HTTP基础知识,包括请求与响应结构,并通过`HttpClient`库演示如何发送GET请求及处理响应,同时分析常见错误并提供解决方案,助你更高效地完成HTTP相关任务。
64 2
|
24天前
|
JSON 缓存 JavaScript
【HTTP】请求“报头”(Host、Content-Length/Content-Type、User-Agent(简称 UA))
【HTTP】请求“报头”(Host、Content-Length/Content-Type、User-Agent(简称 UA))
72 1