http详解笔记

忧愁的chafry

发布于 2022-10-25 14:36:12

2970

发布于 2022-10-25 14:36:12

文章被收录于专栏：个人技术笔记

http详解笔记

http,(HyperText Transfer Protocol),超文本传输协议，亦成为超文本转移协议

通常使用的网络是在TCP/IP协议族的基础上运作的，HTTP属于它的一个子集。

TCP/IP协议族的分层

TCP/IP 协议族按层次分别分

为以下 4 层：应用层、传输层、网络层和数据链路层。

应用层

应用层决定了向用户提供应用服务时通信的活动。 TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。 HTTP 协议也处于该层。

传输层

传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协议）。

网络层（又名网络互连层）

网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。

链路层（又名数据链路层，网络接口层）

用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。

当在网页浏览器的地址栏中输入URL时的完整过程

如何看待三次握手

TCP 位于传输层，提供可靠的字节流服务。

字节流服务（ByteStreamService）是指，为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。而可靠的传输服务是指，能够把数据准确可靠地传给对方。一言以蔽之，TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。

因此采用了三次握手的策略来确保数据能到达目标

原理

握手过程中使用了TCP的标志（flag）——SYN（synchronize）和ACK（acknowledgement）。发送端首先发送一个带SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后，发送端再回传一个带ACK标志的数据包，代表“握手”结束。

若在握手过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包。

展示

详细一点就是

如何看待四次挥手

原理

这种场景会出现的比较多的就是socket使用时，当A方传输完数据后，发起断开连接，B方接受并确认，就关闭B方的接收通道，此时A方还不能关闭。

等待B方发起断开请求，A方确认全部接收完后回复之后，A方才关闭接收通道。

展示

为什么“握手”是三次，“挥手”却要四次

TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。

即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。

为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。

释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

存在的意义

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

HTTP的方法

GET：获取资源

POST：传输实体主体，虽然GET也可以传输实体的主体，但一般使用POST，POST与GET相似，但POST的主要目的不是获取响应的主体。

PUT：传输文件，鉴于PUT自身不带检验机制，任何人都可以上传文件，存在安全性问题，因此一般网站不使用该方法。若配合web应用程序的检验机制，或架构设计采用REST标准的同类WEB网站，就可能会开放PUT方法。

HEAD：获取报文首部，用于确认URI的有效性及资源的更新日期时间等。

DELETE：删除文件，按请求URI删除指定的资源。是与PUT相反的方法。

OPTIONS：询问支持的方法，用来查询针对请求URI指定的资源支持的方法。

TRACE：追踪路径。

CONNECT：要求用隧道协议连接代理。要求在与代理服务器通信时建立隧道，实现隧道协议进行TCP通信。主要使用SSL（安全套接层）和TLS（传输层安全）协议把通信内容加密后经网络隧道传输。

HTTP长连接与短连接

设置HTTP短连接

在首部字段中设置Connection:close，则在一次请求/响应之后，就会关闭连接。

设置HTTP长连接，有过期时间

在首部字段中设置Connection:keep-alive 和Keep-Alive: timeout=60，表明连接建立之后，空闲时间超过60秒之后，就会失效。如果在空闲第58秒时，再次使用此连接，则连接仍然有效，使用完之后，重新计数，空闲60秒之后过期。

设置HTTP长连接，无过期时间

在首部字段中只设置Connection:keep-alive，表明连接永久有效。

实现原理

了解怎么设置之后，就开始用起来。然而，问题来了。在请求头中设置Connection:keep-alive，为什么连接空闲一段时间之后，还是断开了呢？这是因为connection字段只有服务端设置才有效。

HTTP操作是请求/响应成对出现的，即先有客户端发出请求，后有服务端处理请求。所以，一次HTTP操作的终点操作在服务端上，关闭也是由服务端发起的。

HTTP Connection的 close设置允许客户端或服务器中任何一方关闭底层的连接，双方都会要求在处理请求后关闭它们的TCP连接。例：

客户端设置Connection: Keep-Alive和Keep-Alive: timeout=60，服务端设置Connection: Keep-Alive和Keep-Alive: timeout=5。则五秒后长连接会被断开。

注意

另外还有HTTP协议的keep-alive和TCP的keep-alive含义是有差别的。HTTP的keep-alive是为了维持连接，以便复用连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。但是，长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。

而tcp keep-alive是TCP的一种检测TCP连接状况的机制，涉及到三个参数tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes。

当网络两端建立了TCP连接之后，闲置（双方没有任何数据流往来）了tcp_keepalive_time后，服务器内核就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对方的ack。如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。