一次HTTP请求的背后


基础概念


网络七层模型

应用层

提供网络管理、文件传输、事务处理,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报文首部:

  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请求流程

时间线流程

这里写图片描述

网络层级关系


请求流程分析

解析域名(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).

数据传输过程

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

这是流中第一个携带有效数据的包(确切的说,是客户端发送的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

附软件截图

总结

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

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

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

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

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,905评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,140评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,791评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,483评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,476评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,516评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,905评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,560评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,778评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,557评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,635评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,338评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,925评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,898评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,142评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,818评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,347评论 2 342

推荐阅读更多精彩内容