计算机网络

【要点1】TCP/IP五层模型和OSI网络七层协议

Reference

1.1 应用层

"应用层"的作用,就是规定应用程序的数据格式。

举例来说,TCP协议可以为各种各样的程序传递数据,比如Email、WWW、FTP等等。那么,必须有不同协议规定电子邮件、网页、FTP数据的格式,这些应用程序协议就构成了"应用层"。

这是最高的一层,直接面对用户。它的数据就放在TCP数据包的"数据"部分。

HTTP,HTTPS协议,其中HTTP没有对数据进行加密操作,但是HTTPS对数据进行了加密操作 其中HTTP端口号一般是80/8080等等,HTTPS端口号是443,SSH端口号一般是22,ftp是21 HTTP协议报头:

首行:请求方法,url,协议版本
请求报头:
HOST:主机
Connection:长连接还是短连接
Content-Length:标示body的长度
Accept-Encoding:客户告诉服务器编码类型和语言类型
Cookie:在客户端保存少量信息,实现会话的功能
空行
body

1.1.1 域名系统DNS

DNS 系统

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

域名服务器

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

1.1.2 FTP

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

1.1.3 万维网 & HTTP协议

概述

在这里插入图片描述

超文本传输协议HTTP

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

HTTP协议的特点

在这里插入图片描述

HTTP协议的连接方式

在这里插入图片描述

HTTP协议—报文结构

在这里插入图片描述
在这里插入图片描述

1.1.4 电子邮件

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

1.2 传输层

1.2.1 传输层概述

1、传输层功能
在这里插入图片描述

"传输层"的功能,就是建立"端口到端口"的通信。相比之下,“网络层"的功能是建立"主机到主机"的通信。只要确定主机和端口,我们就能实现程序之间的交流。因此,Unix系统就把主机+端口,叫做"套接字”(socket)。有了它,就可以进行网络应用程序开发了。
在这里插入图片描述
2、传输层的寻址与端口
在这里插入图片描述
在这里插入图片描述

1.2.2 UDP协议

1、UDP特点
在这里插入图片描述

2、UDP报头格式

16位源端口号                  16位目的端口号
16位UDP长度                   16位UDP检验和(保证基本的数据正确性数据可以丢失,但不能把错的                       数据传给应用层)
数据

在这里插入图片描述

3、UDP校验
在这里插入图片描述
在这里插入图片描述

4、UDP的缓冲区

UDP是调用sendto将数据直接交给内核,内核将数据交给网络层协议进行后续传输动作,UDP有接受缓冲区,当数据在接收方的缓冲区已经满的时候,此时如果再给对方进行数据发送,数据就会丢失
UDP是基于全双工的,通信双方既可以读,也可以写

5、UDP传输数据

UDP在传输数据的时候最大长度是16位,也就是在传输的过程中最大长度就是64K,如果传输裹过程中数据大于64K,此时就需要应用层将数据进行分包,在到达对方的时候进行解包

1.2.3 TCP协议

1、TCP协议的特点
在这里插入图片描述

2、TCP首部格式
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

HTTP协议报头:

16位源端口号 16位目的端口号
32位序列号
32位确认序列号
4位首部长度 保留6位 标识位 16位窗口大小
16位检验和 16位紧急指针
选项
数据

其中16位的源端口号表示的是来自上层协议中的那个进程,目的端口号表示要交给接受端那个进程.32位序列号和确认序列号保证数据的请求和应答的正确性.同时也可以保证数据的按需到达,由于序列号和序列号也保证了数据的重传机制,也不用再担心丢包问题

1.2.4 TCP与UDP

1、TCP与UDP的区别?

1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付

3、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的

UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)

4、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信

5、TCP首部开销20字节;UDP的首部开销小,只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道

2、为什么UDP有时比TCP更有优势?

UDP以其简单、传输快的优势,在越来越多场景下取代了TCP,如实时游戏。

(1)网速的提升给UDP的稳定性提供可靠网络保障,丢包率很低,如果使用应用层重传,能够确保传输的可靠性。

(2)TCP为了实现网络通信的可靠性,使用了复杂的拥塞控制算法,建立了繁琐的握手过程,由于TCP内置的系统协议栈中,极难对其进行改进。

采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会越来越大,基于UDP对实时性要求较为严格的情况下,采用自定义重传机制,能够把丢包产生的延迟降到最低,尽量减少网络问题对游戏性造成影响。

1.2.5 TCP可靠传输

TCP如何保证传输可靠性

在这里插入图片描述
在这里插入图片描述

  • 确认应答
    TCP传输的过程中,每次接收方收到数据后,都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号,告诉发送方,接收到了哪些数据,下一次的数据从哪里发。从而保证了可靠性传输。
    注: 序列号的作用不仅仅是应答的作用,有了序列号能够将接收到的数据根据序列号排序,并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。

  • 重传
    在这里插入图片描述

在进行TCP传输时,由于确认应答与序列号机制,也就是说发送方发送一部分数据后,都会等待接收方发送的ACK报文,并解析ACK报文,判断数据是否传输成功。如果发送方发送完数据后,迟迟没有等到接收方的ACK报文,这该怎么办呢?而没有收到ACK报文的原因可能是什么呢?

首先,发送方没有接收到响应的ACK报文原因可能有两点:

a、数据在传输过程中由于网络原因等直接全体丢包,接收方没有接收到。

b、接收方接收到了响应的数据,但是发送的ACK报文响应却由于网络原因丢包了。

TCP在解决这个问题的时候引入了一个新的机制,叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间,时间到达没有接收到ACK报文,那么对刚才发送的数据进行重新发送。如果是刚才第一个原因,接收方收到二次重发的数据后,便进行ACK应答。如果是第二个原因,接收方发现接收的数据已存在(判断存在的根据就是序列号,所以上面说序列号还有去除重复数据的作用),那么直接丢弃,仍旧发送ACK应答。

那么发送方发送完毕后等待的时间是多少呢?如果这个等待的时间过长,那么会影响TCP传输的整体效率,如果等待时间过短,又会导致频繁的发送重复的包。如何权衡?

由于TCP传输时保证能够在任何环境下都有一个高性能的通信,因此这个最大超时时间(也就是等待的时间)是动态计算的。

注意:

超时以500ms(0.5秒)为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。重发一次后,仍未响应,那么等待2500ms的时间后,再次重传。等待4500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数,TCP就认为网络或者对端出现异常,强制关闭连接。

  • 流量控制
    在这里插入图片描述
    在这里插入图片描述

在TCP报头中包括了一个窗口大小的字段用来表示自己可以接收的最大报文数量.当主机A向主机B发送一个报文的时候,每次都会看一下主机B的接受窗口,主机B接收到主机A发送给自己的数据之后,此时会将自己的接受窗口写入到TCP报头中窗口字段中,A接受到主机B发送给自己的报文之后,首先先看一下对方窗口大小,如果这个窗口大小比较大了,此时主机A会加快自己发送速度,如果发现接受方的接受窗口比较小的时候,此时就会减慢自己的发送速度,当发现对方的接受窗口为0的时候,此时就会停止自己发送报文.当过一段时间的时候,此时发送方A会给接收方B发送探测数据,以便知道对方的接受窗口的大小。

  • 拥塞控制

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

网卡罗上连接了许多的数据,如果一开始的时候各个主机直接给网络发送很多的数据,此时势必会造成网络拥塞.TCP规定了一个拥塞窗口,表示当前网络能够接受的做大数据,每次发送方在发送的时候都会将对方的窗口大小和拥塞窗口进行比较,将较小的数据作为自己的发送窗口.
同时在发送的时候规定拥塞窗口大小为1,每接收到一个应答便将拥塞窗口加1,当拥塞窗口的大小大于一个阀值的时候,此时将变为线性增长,同时每次超时重传的时候阀值会降为原来的一半.同时将硬塞窗口变为1

1.2.6 TCP保证性能传输

  • 滑动窗口
    滑动窗口左边表示的是已经确认过的,滑动窗口内表示的是已经发出去,但是没有进行确认的,滑动窗口右边的表示的是未发送的数据

  • 延迟应答
    接受方接受到数据后先不对发送方进行确认,经过一段时间后才对对方发送的数据进行一起确认.

  • 捎带应答
    每次接收方在对对方的发送数据进行确认的时候,此时也将自己需要发送给接受方的数据也全部发送给接收方

1.3 网络层

为什么要有网络?

之所以要有网络层,是因为数据在发送方传输层的时候只有自己的源端口和目标端口,但是不知道对方的IP以及数据应该如何到达对方的目的端口都是不知道的,有了网络层,此时加上路由器就会将数据从远端通过路由转发算法对其进行转发,一直到达对方所在的局域网
数据从上层的传输层传下来的时候,此时山层协议有很多,为了区分数据来自上层的哪个协议此时就在IP层的报头中添加了一个8位协议,表示自己接受的数据来自上层协议的那个协议,同时在IP层也有对应的IPV4和IPV6,为了区别两者,也就增加了一个4位版本,同时由于数据进行了封装,那么如和区别自己是正文还是报头信息,此时就需要将自己的数据进行区分,于是便有了首部长度这个字段(4位),同时也有一个8位服务类型,同时16位的总长度表示数据段加上首部整体的长度,由于数据来自上层,有可能数据太大了,于是就需要将数据进行分片,来自上层的同一个数据在经过分片后它的标识是一样的,但是为了防止在IP层对数据进行胡乱的分片,此时就有了3位的表示字段表示是否允许分片.同时既然进行了分片,此时接受方接受到数据后就要进行组装,在进行组装的时候肯定要知道那个数据在前,那个数据在后,于是就需要一个片偏移表示数据的位置,同时在IP层数据要进行路由转发,于是每一个数据都得有自己的一个生存时间,同时也得对首部信息进行校验.既然进行路由转发,此时就需要知道源IP,目的IP,同时也有选项字段(最多40)字节

4位版本 4位首部长度 8位服务类型 16位总长度 16位标识符
3位标识 13位的片偏移 8位生存时间 8位协议
16位首部校验和
32位源IP地址
32位的目的IP地址
选项
数据

网段划分
为什么要有网段划分:
之所以要有网段划分是因为网络中有很多的主机,而在这么多的主机中要去找一个主机,那可能会耗费大量的人力物力,所以为了方便找到网络中的每一个主机
IP包括网络号和主机号,其中网络号是为了保证两个网段具有不同的标识,端口号是为了保证在同一个网络之间的主机有不同的标识
其中同一个子网中的主机之间网络号相同,主机号不同

ICMP
和IP相同的是ICMP也是工作在网络层的,但是ICMP不能保证数据是否成功到达对方,而ICMP可以确认数据是否成功到达对方,同时在进行返回的时候会通知IP报被对其的原因,虽然ICMP只能针对IPV4进行使用

1.4 数据链路层

【要点2】TCP连接管理–TCP的三次握手与四次挥手理解

在这里插入图片描述
序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。

确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。

确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效

同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。

终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接

PS:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。

在这里插入图片描述

三次握手理解

在这里插入图片描述
第一次握手:建立连接时,客户端发送SYN包(seq=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。

第二次握手:服务器收到SYN包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(seq=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
在这里插入图片描述
在这里插入图片描述

四次挥手过程理解

在这里插入图片描述
四次握手是指终止TCP连接协议时,需要在客户端和服务器之间发送四个包

第一次挥手:主动关闭方发送第一个包,其中FIN标志位为1,发送顺序号seq为X。

第二次挥手:被动关闭方收到FIN包后发送第二个包,确认ACK标志位为1,其中发送顺序号seq为Y,接收顺序号(确认序列号)ack为X+1。

第三次挥手:被动关闭方再发送第三个包,其中FIN标志位为1,ACK标志位为1,发送顺序号seq为Z,接收顺序号(确认序列号)ack为X+1。

第四次挥手:主动关闭方发送第四个包,其中发送顺序号seq为X+1,接收顺序号(确认序列号)ack为Z+1。至此,完成四次挥手。

在这里插入图片描述

(1)客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。

(2)服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。

(3)客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。

(4)服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。

(5)客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。

6)服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

超时重传指的是,发送数据包在一定的时间周期内没有收到相应的ACK,等待一定的时间,超时之后就认为这个数据包丢失,就会重新发送。这个等待时间被称为RTO.

常见问题

【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?

答: 建立连接时,ACK和SYN可以放在一个报文里来发送。而关闭连接时,被动关闭方可能还需要发送一些数据后,再发送FIN报文表示同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。具体地:

因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

在这里插入图片描述

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

【问题3】为什么不能用两次握手进行连接

答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。

  • 为了实现可靠数据传输, TCP 协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。三> 次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤
  • 如果只是两次握手,至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认

防止失效的连接请求报文段被服务端接受,从而产生错误。
PS:失效的连接请求:若客户端向服务端发送的连接请求丢失,客户端等待应答超时后就会再次发送连接请求,此时,上一个连接请求就是『失效的』。
若建立连接只需两次握手,客户端并没有太大的变化,仍然需要获得服务端的应答后才进入ESTABLISHED状态,而服务端在收到连接请求后就进入ESTABLISHED状态。此时如果网络拥塞,客户端发送的连接请求迟迟到不了服务端,客户端便超时重发请求,如果服务端正确接收并确认应答,双方便开始通信,通信结束后释放连接。此时,如果那个失效的连接请求抵达了服务端,由于只有两次握手,服务端收到请求就会进入ESTABLISHED状态,等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态,服务端将会一直等待下去,这样浪费服务端连接资源。
详情见:https://www.cnblogs.com/cenglinjinran/p/8482412.html

两次握手容易死锁。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发
送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S
是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分
组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?

TCP还设有一个保活计时器(keepalive timer),显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

Reference

【要点3】搜索框输入url到呈现搜索结果的过程

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求,浏览器得到html代码 --> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等) --> 浏览器对页面进行渲染呈现给用户

  • 浏览器向DNS(Domain Name Server)请求,DNS将域名转换为对应的IP地址。

  • 浏览器连接到Web服务器HTTP/80端口,三次握手创建TCP连接。

  • 浏览器发送HTTP请求,读取URL域名后面对应文件,并注意该请求作为TCP三次握手中的第三次握手的数据发送给Web服务器。

  • 服务器接收HTTP请求并返回HTTP响应,响应体中存放对应的html文本。

  • 如果CONNECITON模式为close,立刻四次挥手释放TCP连接;若CONNECTION模式为keep-alive,则保持该连接一段时间后再释放,这段时间内还可以接受请求。

  • 浏览器解析html文本内容并显示。

1.域名解析,根据用户输入的网址去寻找它对应的IP地址。具体地,浏览器发起DNS查询请求,域名服务器向客户端返回查询结果域名,从而完成域名到IP地址的转换。

在广域网中,我们是基于IP地址进行通信的。但通常客户访问的是一个网址,为此,我们需要先得到网址对应的IP地址,这就需要域名服务系统将域名转换成IP地址。如下图所示,在客户端浏览器中输入网址:http://www.cricode.com时,浏览器会根据本地客户端DNS服务器配置(下图为DNS服务器配置),向DNS服务器获取域名对应的IP地址。

域名解析服务器是基于UDP协议实现的一个应用程序,通常通过监听53端口来获取客户端的域名解析请求。

2.建立TCP连接

  • 先是客户端发起请求过程:
  1. 使用应用层发起HTTP请求(这个可以根据你本身输入的url访问时,用的什么协议就发起对应协议去进行请求)
  2. 然后是传输层的TCP协议为传输报文提供可靠的字节流服务,这里也就使用了TCP三次握手
  3. 网络层是把TCP分割好的各种数据包传送给接收方。而要保证确实能传到接收方还需要接收方的MAC地址,也就是物理地址
  4. 然后才是链路层将数据发送到数据链路层传输。至此请求报文已发出,客户端发送请求的阶段结束
  • 然后是服务端接受请求处理阶段:

原路进行处理:链路层—>网络层—>传输层—>应用层然后响应客户端发送报文。

3.建立TCP连接后客户端向web服务器发送HTTP请求

在得到了域名对应的IP地址后,客户端便可以向真正的web服务器发生HTTP请求了。通常一个HTTP请求格式如下:

GET http://www.cricode.com/ HTTP/1.1
Host: www.cricode.com
Connection: keep-alive
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8

HTTP请求是一个基于TCP协议之上的应用层协议——超文本传输协议。浏览器通过DNS获取到web服务器真的IP地址后,便向web服务器发起tcp连接请求,通过TCP三次握手建立好连接后,浏览器便可以将HTTP请求数据通过发送给服务器了。

4.发送响应数据给客户端。服务器端响应http请求,浏览器得到html代码

Web服务器通常通过监听80端口,来获取客户端的HTTP请求。与客户端建立好TCP连接后,web服务器开始接受客户端发来的数据,并通过HTTP解码,从接受到的网络数据中解析出请求的url信息以前其他诸如Accept-Encoding、Accept-Language等信息。

Web服务器根据HTTP请求头的信息,得到响应数据返回给客户端。

一个典型的HTTP响应头数据报如下:

HTTP/1.1 200 OK
Date: Fri, 24 Oct 2014 13:55:18 GMT
Server: Apache
X-Powered-By: PHP/5.4.32
Keep-Alive: timeout=5, max=10000
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
a0f6

快课网— 程序员的自我修养! 至此,一个HTTP通信过程完成。web服务器会根据HTTP请求头中的Connection字段值决定是否关闭TCP链接通道,当Connection字段值为keep-alive时,web服务器不会立即关闭此连接。

5. 浏览器解析html代码,并请求html代码中的资源

浏览器拿到index.html文件后,就开始解析其中的html代码,遇到js/css/image等静态资源时,就向服务器端去请求下载(会使用多线程下载,每个浏览器的线程数不一样),这个时候就用上keep-alive特性了,建立一次HTTP连接,可以请求多个资源,下载资源的顺序就是按照代码里的顺序,但是由于每个资源大小不一样,而浏览器又多线程请求请求资源,所以从下图看出,这里显示的顺序并不一定是代码里面的顺序。

浏览器在请求静态资源时(在未过期的情况下),向服务器端发起一个http请求(询问自从上一次修改时间到现在有没有对资源进行修改),如果服务器端返回304状态码(告诉浏览器服务器端没有修改),那么浏览器会直接读取本地的该资源的缓存文件。

6.浏览器对页面进行渲染呈现给用户

最后,浏览器利用自己内部的工作机制,把请求到的静态资源和html代码进行渲染,渲染之后呈现给用户。

自此一次完整的HTTP事务宣告完成.

【要点4】HTTP与HTTPS的区别

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值