从前端看HTTP的应用(network, tcp,udp,三次握手)

我们在前端开发中经常用到chrome浏览器的network来查看,调试HTTP、HTTPS的网络请求。

我们先来看的Network的使用。

Chrome的Network

我们平时能从Network里看的如下图

我们能看到HTTP/HTTPS请求的地址,协议,请求的大小,时间等。更多的信息可在title栏右键然后选择即可


点击某条请求可以查看详细信息

header里的东西我们就不多说了,我们看下timing里的信息


1. Queuing(排队中)

如果一个请求排队,则表明:

1)请求被渲染引擎推迟,因为它被认为比关键资源(如脚本/样式)的优先级低。这经常发生在 images(图像) 上。

2)这个请求被搁置,在等待一个即将被释放的不可用的TCP socket。

3)这个请求被搁置,因为浏览器限制。在HTTP 1协议中,每个源上只能有6个TCP连接,这个问题将在下一面的章节中提到。

4)正在生成磁盘缓存条目(通常非常快)。

2.Stalled/Blocking (停止/阻塞)

发送请求之前等待的时间。它可能因为进入队列的任何原因而被阻塞。这个时间包括代理协商的时间。

3.Proxy Negotiation (代理协商)

与代理服务器连接协商花费的时间

4.DNS Lookup (DNS查找)

执行DNS查找所用的时间。 页面上的每个新域都需要完整的往返(roundtrip)才能进行DNS查找。当本地DNS缓存没有的时候,这个时间可能是有一段长度的,但是比如你一旦在host中设置了DNS,或者第二次访问,由于浏览器的DNS缓存还在,这个时间就为0了。

5.Initial Connection / Connecting (初始连接/连接)

建立连接所需的时间, 包括TCP握手/重试和协商SSL。

6.SSL

完成SSL握手所用的时间,如果是HTTPS的话

7.Request Sent / Sending (请求已发送/正在发送)

发出网络请求所花费的时间。 通常是几分之一毫秒。

8.Waiting (TTFB) (等待)

等待初始响应所花费的时间,也称为`Time To First Byte`(接收到第一个字节所花费的时间)。这个时间除了等待服务器传递响应所花费的时间之外,还捕获到服务器发送数据的延迟时间。这些情况可能会导致高TTFB:1.客户端和服务器之间的网络条件差;2.服务器端程序响应很慢。

9.Content Download / Downloading (内容下载/下载)

接收响应数据所花费的时间。从接收到第一个字节开始,到下载完最后一个字节结束。

通过对请求发出和响应的每个阶段的理解,我们就能分析出当前HTTP请求存在的问题,并据此解决问题。


客户端与服务端通过HTTP协议的交互过程(TCP/IP的三次握手)


1、浏览器向服务器发出连接请求,并发送SYN包,进入SYN_SEND状态,等待服务器确认。这是TCP三次握手的第一次。

2、服务器响应了浏览器的请求,确认浏览器的SYN(ACK=J+1),并且自己也发送SYN包也就是SYN+ACK包,要求浏览器进行确认,此时了服务器进入SYN_RECV状态。这是TCP三次握手的第二次。

3、浏览器响应了服务器的SYN+ACK包,向服务器发送确认包ACK(ACK=K+1),此包发送完毕,浏览器和服务器进入ESTABLISHED状态,这是TCP三次握手的第三次,握手完成,TCP连接成功建立。

三次请求可以这么理解,相当于2个人进行对话,

甲乙两个人路上遇见

第一次握手相当于甲向乙打个招呼,看乙是否能够接收到甲打的招呼。这时甲进入等待状态。

第二次握手相当于乙听到了甲的招呼,进行回应(相当于告诉甲乙可以接收到并能理解甲的招呼)并向甲打招呼看甲是否能接收到乙的招呼,这时乙进入等待状态

第三次是甲接收到乙的回应知道乙可以接收到甲的信息并能理解,并且回应了乙的招呼,告诉乙这时候甲能接受乙的信息并能理解。这时候就能确定双方都可以接收到对方的信息并能进行正常的对话。下一步就开始对话。也就是信息传输。

网络的OSI7层模型

前面提到的三次握手发生在传输层,实际不是在这个OSI的7层模型内。

TCP和UDP

tcp 需要进行三次握手来确定连接的可靠性在进行传输

udp 不需要进行确定而直接进行传输

优缺点

TCP的优点:

 可靠,稳定 TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源。 

TCP的缺点:

 慢,效率低,占用系统资源高,易被攻击 TCP在传递数据之前,要先建连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞控制机制等都会消耗大量的时间,而且要在每台设备上维护所有的传输连接,事实上,每个连接都会占用系统的CPU、内存等硬件资源。 而且,因为TCP有确认机制、三次握手机制,这些也导致TCP容易被人利用。

UDP的优点:

 快,比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制,UDP是一个无状态的传输协议,所以它在传递数据时非常快。没有TCP的这些机制,UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的

 UDP的缺点: 

不可靠,不稳定 因为UDP没有TCP那些可靠的机制,在数据传递时,如果网络质量不好,就会很容易丢包。 

基于上面的优缺点,那么: 什么时候应该使用TCP: 当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议。 在日常生活中,常见使用TCP协议的应用如下: 浏览器,用的HTTP FlashFXP,用的FTP Outlook,用的POP、SMTP Putty,用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP: 当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,这时就可以使用UDP。 比如,日常生活中,常见使用UDP协议的应用如下: QQ语音 QQ视频 TFTP ……


HTTP阻塞

HTTP1.1默认只能同时创建6条TCP连接,每条连接结束以后才能释放出来给对另外一个资源的请求来使用。虽然和HTTP1.0相比,在性能上已有较大提升,但是并没有本质的改变。以本项目为例,如果当瞬间发起满10个请求后,只有前6个请求能够分配6个不同的HTTP连接进行处理,后续4个请求只有等待这6个请求有任何一个释放HTTP连接资源以后,才能继续。也就是说前6个请求中如果最少耗时都在1s,那么后4个请求的最少Pending时间都在1s。

可以发现阻塞现象相当严重,而且每个HTTP请求会创建一个独立的TCP连接进行处理,请求完成以后再关闭,再为下一次请求创建一个新的HTTP连接,资源开销极大。这里keep-alive虽然开着的,但是server端没有设置connection: true,所以暂没法保持连接。

我们可以通过Network查看是否是一次连接,通过Connection ID来查看


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章