美文网首页
Http和TCP/IP协议

Http和TCP/IP协议

作者: 坤坤坤坤杨 | 来源:发表于2021-09-14 19:01 被阅读0次

    1. 网络协议以及体系结构

    1.1 OSI体系结构, TCP/IP体系结构,5层体系结构的对应关系

    五层协议只是OSI和TCP/IP的综合,实际应用还是TCP/IP的四层结构。为了方便可以把下两层称为网络接口层。

    image

    OSI 7层

    OSI七层参考模型的各个层次的划分遵循下列原则:

    • 同一层中的各网络节点(理解为电脑)都有相同的层次结构,具有同样的功能。

    • 同一节点内相邻层之间通过接口(可以是逻辑接口)进行通信。

    • 七层结构中的每一层使用下一层提供的服务,并且向其上层提供服务。

    • 不同节点的同等层按照协议实现对等层之间的通信。

    1. 物理层:规定通信设备的机械的、电气的、功能的和过程的特性,用以建立、维护和拆除物理链路连接。具体地讲,机械 特性规定了网络连接时所需接插件的规格尺寸、引脚数量和排列情况等;电气特性规定了在物理连接上传输bit流时线路上信号电平的大小、阻抗匹配、传输速率 距离限制等;功能特性是指对各个信号先分配确切的信号含义,即定义了DTE和DCE之间各个线路的功能;规程特性定义了利用信号线进行bit流传输的一组 操作规程,是指在物理连接的建立、维护、交换信息是,DTE和DCE双放在各电路上的动作系列。在这一层,数据的单位称为比特(bit)。
    1. 数据链路层:在物理层提供比特流服务的基础上,建立相邻结点之间的数据链路,通过差错控制提供数据帧(Frame)在信道上无差错的传输,并进行各电路上的动作系列。数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括:物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。在这一层,数据的单位称为帧(frame)。链路层规定了一个特性:(物理帧的大小)最大传输单元MTU:对数据帧长度的一种限制,以太网和802.3对数据帧长度限制的最大值分别是1500字节和1429字节。不同物理网络技术的MTU不同。
    1. 网络层:在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路,也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。网络层将数据链路层提供的帧组成数据包,包中封装有网络层报头,其中含有逻辑地址信息——源站点和目的站点地址的网络地址。如 果你在谈论一个IP地址,那么你是在处理第3层的问题,这是“数据包”问题,而不是第2层的“帧”。IP是第3层问题的一部分,此外还有一些路由协议和地 址解析协议(ARP)。有关路由的一切事情都在这第3层处理。地址解析和路由是3层的重要目的。网络层还可以实现拥塞控制、网际互连等功能。在这一层,数据的单位称为数据包(packet)。网络层协议的代表包括:IP、IPX、RIP、OSPF等。
    1. 传输层:第4层的数据单元也称作数据包(packets)。但是,当你谈论TCP等具体的协议时又有特殊的叫法,TCP的数据单元称为段 (segments)而UDP协议的数据单元称为数据报(datagrams)。这个层负责获取全部信息,因此,它必须跟踪数据单元碎片、乱序到达的 数据包和其它在传输过程中可能发生的危险。第4层为上层提供端到端(最终用户到最终用户)的透明的、可靠的数据传输服务。所谓透明的传输是指在通信过程中 传输层对上层屏蔽了通信传输系统的具体细节。传输层协议的代表包括:TCP、UDP等。
    1. 会话层:这一层也可以称为会晤层或对话层,在会话层及以上的高层次中,数据传送的单位不再另外命名,而是统称为报文。会话层不参与具体的传输,它提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制。如服务器验证用户登录便是由会话层完成的。
    1. 表示层:这一层主要解决拥护信息的语法表示问题。它将欲交换的数据从适合于某一用户的抽象语法,转换为适合于OSI系统内部使用的传送语法。即提供格式化的表示和转换数据服务。数据的压缩和解压缩, 加密和解密等工作都由表示层负责。
    1. 应用层:应用层为操作系统或网络应用程序提供访问网络服务的接口。应用层协议的代表包括:Telnet、FTP、HTTP等。

    1.2 网络层次与数据传递

    image image

    1.3 各层中的设备

    OSI 七层模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯,因此其最主要的功能就是帮助不同类型的主机实现数据传输 。完成中继功能的节点通常称为中继系统。

    一个设备工作在哪一层,关键看它工作时利用哪一层的数据头部信息。网桥工作时,是以MAC头部来决定转发端口的,因此显然它是数据链路层的设备。具体说:

    • 物理层:网卡,网线,集线器,中继器,调制解调器
    • 数据链路层:网桥,交换机
    • 网络层:路由器
    • 网关工作在第四层传输层及其以上   集线器是物理层设备,采用广播的形式来传输信息。

    交换机就是用来进行报文交换的机器。多为链路层设备(二层交换机),能够进行地址学习,采用存储转发的形式来交换报文。

    路由器的一个作用是连通不同的网络,另一个作用是选择信息传送的线路。选择通畅快捷的近路,能大大提高通信速度,减轻网络系统通信负荷,节约网络系统资源,提高网络系统畅通率。

    1.4 各层中的协议

    image

    2. TCP/IP协议

    2.1 IP

    因为网络层是整个互联网的核心,因此应当让网络层尽可能简单。网络层向上只提供简单灵活的、无连接的、尽最大努力交互的数据报服务。

    使用 IP 协议,可以把异构的物理网络连接起来,使得在网络层看起来好像是一个统一的网络。

    ip的功能:

    1. 路由寻址

    2. 数据分片

    2.1.1 IP数据报格式

    image

    版本 : 有 4(IPv4)和 6(IPv6)两个值;

    首部长度 : 占 4 位,因此最大值为 15。因为固定部分长度为 20 字节,因此该值最小为 5。如果可选字段的长度不是 4 字节的整数倍,就用尾部的填充部分来填充。

    区分服务 : 用来获得更好的服务,一般情况下不使用。

    总长度 : 包括首部长度和数据部分长度。

    生存时间 :TTL,它的存在是为了防止无法交付的数据报在互联网中不断兜圈子。以路由器跳数为单位,当 TTL 为 0 时就丢弃数据报。

    协议 :指出携带的数据应该上交给哪个协议进行处理,例如 ICMP、TCP、UDP 等。

    首部检验和 :因为数据报每经过一个路由器,都要重新计算检验和,因此检验和不包含数据部分可以减少计算的工作量。

    标识 : 在数据报长度过长从而发生分片的情况下,相同数据报的不同分片具有相同的标识符。

    片偏移 : 和标识符一起,用于发生分片的情况。片偏移的单位为 8 字节。

    image

    2.1.2 分片和重组

    对数据报进行分片的原因?

    片偏移的作用?为什么需要片偏移?

    在分组的传输通路上,分片操作只能出现在两个MTU不同的网络的交界处,也就是出现在路由器上;进入一个新网络时,若新网络的MTU小于原有网络的MTU,则可能需要进行分片;若新MTU值不小于原有MTU就不必进行分片。

    重组:重组是分片的逆过程。所有的重组操作都在目的主机上进行。

    2.1.3 IPV6

    我国在2014-2015年也逐步停止了向新用户和应用分配 IPv4 地址。 解决 IP 地址耗尽的根本措施就是采用具有更大地址空间的新版本的 IP,即 IPv6。

    • 更大的地址空间。IPv6 将地址从 IPv4 的 32 位 增大到了 128 位

    • 扩展的地址层次结构。

    • 灵活的首部格式。 IPv6 定义了许多可选的扩展首部。

    • 改进的选项。 IPv6 允许数据报包含有选项的控制信息,其选项放在有效载荷中。

    • 允许协议继续扩充。

    • 支持即插即用(即自动配置)。因此 IPv6 不需要使用 DHCP。

    • 支持资源的预分配。 IPv6 支持实时视像等要求,保证一定的带宽和时延的应用。

    • IPv6 首部改为 8 字节对齐。首部长度必须是 8 字节的整数倍。原来的 IPv4 首部是 4 字节对齐。

    IPV6数据包格式:

    image

    V4向V6过渡:

    向 IPv6 过渡只能采用逐步演进的办法,同时,还必须使新安装的 IPv6 系统能够向后兼容:IPv6 系统必须能够接收和转发 IPv4 分组,并且能够为 IPv4 分组选择路由。

    由于IPv6本身不兼容IPv4,大规模部署IPv6还面临不少挑战。目前可行的办法是使用过渡技术,将IPv4逐渐演进到IPv6,当前主要有两种主流的过渡技术

    两种向 IPv6 过渡的策略:

    • 使用双协议栈

    • 使用隧道技术

    双协议栈:主机在和 IPv6 主机通信时是采用 IPv6 地址,而和 IPv4 主机通信时就采用 IPv4 地址。 根据 DNS 返回的地址类型可以确定使用 IPv4 地址还是 IPv6 地址。要求所有的节点都支持双协议栈

    image

    隧道技术:在 IPv6 数据报要进入IPv4网络时,把 IPv6 数据报封装成为 IPv4 数据报,整个的 IPv6 数据报变成了 IPv4 数据报的数据部分。 当 IPv4 数据报离开 IPv4 网络中的隧道时,再把数据部分(即原来的 IPv6 数据报)交给主机的 IPv6 协议栈。

    image

    IPV6的分片功能

    IPv6禁止中间节点设备对IP报文进行分片。事实上,IPv6不能完全放弃分片机制,只是说它用一种完全不同的机制来实现分片:

    • 分片只能在端到端进行!分片和重组只能在端主机进行。

    • 分片信息不在IPv6协议标准头里,而单独设计一个扩展头存放。

    IPv6禁止了中间设备分片,卸载了一些信息处理流程。最终目的是让IPv6报头成为固定的长度,且内部字段对齐,便于高效预取或者直接通过固定硬件处理,从而达到提高处理性能的目的。

    2.2 TCP

    首先,我们需要知道TCP在网络OSI的七层模型中的第四层——Transport层,IP在第三层——Network层,ARP在第二层——Data Link层,在第二层上的数据,我们叫Frame,在第三层上的数据叫Packet,第四层的数据叫Segment。

    我们程序的数据首先会打到TCP的Segment中,然后TCP的Segment会打到IP的Packet中,然后再打到以太网Ethernet的Frame中,传到对端后,各个层解析自己的协议,然后把数据交给更高层的协议处理。

    2.2.1 TCP头格式

    image

    注意上图中的四个非常重要的东西:

    TCP的包是没有IP地址的,那是IP层上的事。但是有源端口和目标端口。

    一个TCP连接需要四个元组来表示是同一个连接(src_ip, src_port, dst_ip, dst_port)准确说是五元组,还有一个是协议。但因为只是说TCP协议所以只说四元组。

    • Sequence Number是包的序号,用来解决网络包乱序(reordering)问题。
    • Acknowledgement Number就是ACK——用于确认收到,用来解决不丢包的问题。
    • Window又叫Advertised-Window,也就是著名的滑动窗口(Sliding Window),用于解决流控的。
    • TCP Flag ,也就是包的类型,主要是用于操控TCP的状态机的。

    2.2.2 TCP状态机

    其实,网络上的传输是没有连接的,包括TCP也是一样的。而TCP所谓的“连接”,其实只不过是在通讯的双方维护一个“连接状态”,让它看上去好像有连接一样。所以,TCP的状态变换是非常重要的。

    image image

    2.2.3 三次握手四次挥手

    建立连接

    在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。

    第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;

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

    第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

    完成三次握手,客户端与服务器开始传送数据,也就是ESTABLISHED状态。

    结束连接

    TCP有一个特别的概念叫做half-close,这个概念是说,TCP的连接是全双工(可以同时发送和接收)连接,因此在关闭连接的时候,必须关闭传和送两个方向上的连接。客户机给服务器一个FIN为1 的TCP报文,然后服务器返回给客户端一个确认ACK报文,并且发送一个FIN报文,当客户机回复ACK报文后(四次握手),连接就结束了。

    为什么建立连接是三次握手断开连接是四次挥手?

    对于建链接的3次握手,主要是要初始化Sequence Number 的初始值。通信的双方要互相通知对方自己的初始化的Sequence Number(缩写为ISN:Inital Sequence Number)——所以叫SYN,全称Synchronize Sequence Numbers。也就上图中的 x 和 y。这个号要作为以后的数据通信的序号,以保证应用层接收到的数据不会因为网络上的传输的问题而乱序(TCP会用这个序号来拼接数据)。

    对于4次挥手,其实仔细看是2次,因为TCP是全双工的,所以发送方和接收方都需要Fin和Ack。只不过有一方是被动的,所以看上去就成了所谓的4次挥手。如果两边同时断连接,那就会就进入到CLOSING状态,然后到达TIME_WAIT状态。

    1. 两次握手是最基本的,一般情况下能保证tcp连接正常进行。
    1. 需要第三次握手是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判 。假如没有第三次握手,服务端接收到失效的请求报文段就会认为连接已建立,从而进入等待客户端发送数据的状态。但客户端并没有发出请求,所以不会发送数据。于是服务端就会一直处于等待状态,从而浪费资源。
    1. 第三次握手失败后:
    *   在第二次握手,服务器端向客户端发送SYN+ACK报文后,就会启动一个定时器,等待客户端返回的ACK报文。
        
        
    *   如果第三次握手失败的话,客户端给服务端返回了ACK报文,服务端并不能收到这个ACK报文。那么服务端就会启动超时重传机制,超过规定时间后重新发起第二次握手,向客户端发送SYN+ACK。
        
        
    *   如果重传指定次数到了后,仍然未收到ACK应答,那么一段时间后,服务端会自动关闭这个连接。但客户端认为这个连接已经建立,如果客户端向服务端写数据,服务端将回应RST包、强制关闭TCP连接,以防止SYN攻击。
    

    2.3 TCP滑动窗口

    如果不了解TCP的滑动窗口,等于不了解TCP协议。

    TCP必需要解决的可靠传输以及包乱序(reordering)的问题,所以,TCP必需要知道网络实际的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包。所以TCP引入了一些技术和设计来做网络流控,Sliding Window是其中一个技术。 前面我们说过,TCP头里有一个字段叫Window,又叫Advertised-Window,这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。 为了说明滑动窗口,我们需要先看一下TCP缓冲区的一些数据结构:

    image

    上图中,我们可以看到:

    • 接收端LastByteRead指向了TCP缓冲区中读到的位置,NextByteExpected指向的地方是收到的连续包的最后一个位置,LastByteRcved指向的是收到的包的最后一个位置,我们可以看到中间有些数据还没有到达,所以有数据空白区。

    • 发送端的LastByteAcked指向了被接收端Ack过的位置(表示成功发送确认),LastByteSent表示发出去了,但还没有收到成功确认的Ack,LastByteWritten指向的是上层应用正在写的地方。

    于是:

    • 接收端在给发送端回ACK中会汇报自己的AdvertisedWindow = MaxRcvBuffer – LastByteRcvd – 1;

    • 而发送方会根据这个窗口来控制发送数据的大小,以保证接收方可以处理。

    下面我们来看一下发送方的滑动窗口示意图:

    image

    上图中分成了四个部分,分别是:(其中那个黑模型就是滑动窗口)

    • 1已收到ack确认的数据。

    • 2发还没收到ack的。

    • 3在窗口中还没有发出的(接收方还有空间)。

    • 4窗口以外的数据(接收方没空间)

    下面是个滑动后的示意图(收到36的ack,并发出了46-51的字节):

    image

    3.1 什么是Http?

    超文本传输协议,是一个基于请求与响应,无状态的,应用层的协议,常基于TCP/IP协议传输数据,互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

    HTTP是一个客户端终端(用户)和服务器端(网站)请求和应答的标准。通过使用网页浏览器、网络爬虫或者其它的工具,客户端发起一个HTTP请求到服务器上指定端口(默认端口为80)。我们称这个客户端为用户代理程序(user agent)。应答的服务器上存储着一些资源,比如HTML文件和图像。我们称这个应答服务器为源服务器。在用户代理和源服务器中间可能存在多个中间层,比如代理服务器、网关或者隧道(tunnel)。

    尽管TCP/IP协议是互联网上最流行的应用,HTTP协议中,并没有规定必须使用它或它支持的层。事实上,HTTP可以在任何互联网协议上,或其他网络上实现。HTTP假定其下层协议提供可靠的传输。因此,任何能够提供这种保证的协议都可以被其使用。因此也就是其在TCP/IP协议族使用TCP作为其传输层。

    通常,由HTTP客户端发起一个请求,创建一个到服务器指定端口(默认是80端口)的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求,服务器会向客户端返回一个状态,比如"HTTP/1.1 200 OK",以及返回的内容,如请求的文件、错误消息、或者其它信息

    版本 产生时间 内容 发展现状
    HTTP/0.9 1991年 不涉及数据包传输,规定客户端和服务器之间通信格式,只能GET请求 没有作为正式的标准
    HTTP/1.0 1996年 传输内容格式不限制,增加PUT、PATCH、HEAD、 OPTIONS、DELETE命令 正式作为标准
    HTTP/1.1 1997年 持久连接(长连接)、节约带宽、HOST域、管道机制、分块传输编码 2015年前使用最广泛
    HTTP/2 2015年 多路复用、服务器推送、头信息压缩、二进制协议等 逐渐覆盖市场

    3.1.1 URL

    URI 包含 URL 和 URN,目前 WEB 只有 URL 比较流行,所以见到的基本都是 URL。

    • URI(Uniform Resource Identifier,统一资源标识符)

    • URL(Uniform Resource Locator,统一资源定位符)

    • URN(Uniform Resource Name,统一资源名称)

    image

    3.1.2 请求报文和响应报文

    请求报文 响应报文

    image image

    3.1.3 状态码

    服务器返回的 响应报文 中第一行为状态行,包含了状态码以及原因短语,用来告知客户端请求的结果。

    状态码 类别 原因短语
    1XX Informational(信息性状态码) 接收的请求正在处理
    2XX Success(成功状态码) 请求正常处理完毕
    3XX Redirection(重定向状态码) 需要进行附加操作以完成请求
    4XX Client Error(客户端错误状态码) 服务器无法处理请求
    5XX Server Error(服务器错误状态码) 服务器处理请求出错

    3.1.4 工作原理

    HTTP协议定义Web客户端如何从Web服务器请求Web页面,以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文,请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应,响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

    以下是 HTTP 请求/响应的步骤:

    1. 客户端连接到Web服务器:一个HTTP客户端,通常是浏览器,与Web服务器的HTTP端口(默认为80)建立一个TCP套接字连接。例如,http://www.baidu.com

    2. 发送HTTP请求:通过TCP套接字,客户端向Web服务器发送一个文本的请求报文,一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

    3. 服务器接受请求并返回HTTP响应:Web服务器解析请求,定位请求资源。服务器将资源复本写到TCP套接字,由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

    4. 释放连接TCP连接:若connection 模式为close,则服务器主动关闭TCP连接,客户端被动关闭连接,释放TCP连接;若connection 模式为keepalive,则该连接会保持一段时间,在该时间内可以继续接收请求;

    5. 客户端浏览器解析HTML内容:客户端浏览器首先解析状态行,查看表明请求是否成功的状态代码。然后解析每一个响应头,响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML,根据HTML的语法对其进行格式化,并在浏览器窗口中显示。

    例如:在浏览器地址栏键入URL,按下回车之后会经历以下流程:

    1. 浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;

    2. 解析出 IP 地址后,根据该 IP 地址和默认端口 80,和服务器建立TCP连接;

    3. 浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求,该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;

    4. 服务器对浏览器请求作出响应,并把对应的 html 文本发送给浏览器;

    5. 释放 TCP连接;

    6. 浏览器将该 html 文本并显示内容;

    image

    基于 请求-响应 的模式

    HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并 返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有 接收到请求之前不会发送响应

    image

    无状态保存

    HTTP是一种不保存状态,即无状态(stateless)协议。HTTP协议 自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个 级别,协议对于发送过的请求或响应都不做持久化处理。无状态不代表 HTTP 不能保持 TCP 连接,更不能代表 HTTP 使用的是 UDP 协议(无连接)。

    image

    使用HTTP协议,每当有新的请求发送时,就会有对应的新响应产 生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把HTTP协议设计成 如此简单的。可是,随着Web的不断发展,因无状态而导致业务处理变得棘手 的情况增多了。比如用户登录到一家购物网站,即使他跳转到该站的 其他页面后,也需要能继续保持登录状态。针对这个实例,网站为了能够掌握是谁送出的请求,需要保存用户的状态。HTTP/1.1虽然是无状态协议,但为了实现期望的保持状态功能, 于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管理状态了。

    无连接

    无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间,并且可以提高并发性能,不能和每个用户建立长久的连接,请求一次响应一次,服务端和客户端就中断了。但是无连接有两种方式,早期的http协议是一个请求一个响应之后,直接就断开了,但是现在的http协议1.1版本不是直接就断开了,而是等几秒钟,如果用户在这几秒钟之内有新的请求,那么还是通过之前的连接通道来收发消息,如果过了这几秒钟用户没有发送新的请求,那么就会断开连接,这样可以提高效率,减少短时间内建立连接的次数,因为建立连接也是耗时的,默认的好像是3秒,这个时间是可以通过后端调整的,所以可以根据网站用户的行为来分析统计出一个最优的等待时间。

    可见,HTTP不是字面意义上的没有连接,事实上,这个定义也符合HTTP短连接的定义,但无连接强调的是HTTP的特性,短连接可理解为一种实现

    长连接和短连接

    HTTP 对 TCP 连接的使用,分为两种方式:俗称“短连接”和“长连接”(“Keep-Alive”或“Persistent Connection”)

    长连接:当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

    • HTTP/0.9:最早发布的1991年0.9版,该时期的HTTP协议十分简单,只支持Get请求,采用短连接的方式,也就是说,客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源(如JavaScript文件、图像文件、CSS文件等),每遇到这样一个Web资源,浏览器就会重新建立一个HTTP会话。
    • HTTP/1.0:1996年发布,默认使用短连接,提出长连接(也叫持久连接)的概念,但当时仅提供初步的支持。
    • HTTP/1.1:1999年发布,默认使用长连接,用以保持连接特性。使用长连接的HTTP协议,会在响应头加入这行代码:Connection:keep-alive

    如果HTTP1.1版本的HTTP请求报文不希望使用长连接,则要在HTTP请求报文首部加上Connection: close。

    短连接:客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。双方任意都可以发起close操作,一般都是client先发起close操作。优点是:管理起来比较简单,存在的连接都是有用的连接,不需要额外的控制手段。也可以这样说:短连接是指Socket连接后发送后接收完数据后马上断开连接。

    HTTP协议的长连接和短连接,实质上是TCP协议的长连接和短连接。

    TCP短连接长连接都由客户端发起,而TCP长连接的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开,则会使得服务器上保留一个半开放的连接,而服务器又在等待来自客户端的数据,此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接,并根据响应决定是否关闭连接。因为短连接、长连接的实现在HTTP之外,与HTTP无关,从HTTP自身来看,HTTP依然是无连接的。

    3.1.5 GET和POST

    image

    相关文章

      网友评论

          本文标题:Http和TCP/IP协议

          本文链接:https://www.haomeiwen.com/subject/clzcgltx.html