简记HTTP协议&长连接短链接

简记HTTP协议及长连接短链接

摘要:

本文主要深入记录Http协议,对Http协议进行深入了解;

笔记中会对中不易理解的难点以及关键点进行记录对简单容易理解的内容简单记录即可;

1 HTTP概念以及工作流程

Http协议的概念字面意思上就是"协议",很大白话的一句话,现实生活中,我们也会在不同场合用到协议,比如你入职你个公司,公司不会任由你想做什么就做什么,入职时会给你签署这个协议,你按照协议办事,就会被认可,如果违反协议办事,那么公司就不会认同做的事;在计算机网络中,如果如果想要在客户端(浏览器,手机浏览器等)与web服务器通信就需要遵守这样一份协议: HTTP协议,字面意思就是超文本传输协议;

w3cSchool给Http的定义是这样的:

HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。

HTTP是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)

1.1 TCP/IP

因为上面讲到HTTP协议是基于TCP/IP进行数据传输的,那么TCP/IP到底是什么呢?

大致概括: TCP是一个面向连接,安全可靠的传输控制层协议;

W3C的定义:

TCP/IP 是供已连接因特网的计算机进行通信的通信协议 ;

TCP/IP 指传输控制协议/网际协议 ;

TCP/IP 定义了电子设备(比如计算机)如何连入因特网,以及数据如何在它们之间传输的标准 ;

  • TCP (传输控制协议) - 应用程序之间通信
  • IP (网际协议) - 计算机之间的通信
在计算机网络中,计算机体系结构其实是很复杂的:
    在没有分层解耦之前,计算的网络体系从底层开始大致是这样的一个结构:
物理层--> 数据链路层--> 网络层--> 运输层--> 会话层--> 表示层--> 应用层
    再进行解耦分层:
物理层--> 数据链路层--> 网络层--> 传输控制层--> 应用层
我们的HTTP协议其实就是属于  应用层  的一个协议,
而物理层是最接近底层的层级,跟计算机硬件就有很多关系了,
而我们的TCP/IP协议就是属于应用层的上一层:  传输控制层  

其实我们发送的HTTP请求,去服务器获取数据,就是通过应用层去调用的传输控制层来完成的,而传输控制层有TCP和UDP这样两个协议,HTTP请求是通过TCP来完成数据的传输和控制的;

1.2 TCP的三次握手(面向连接可靠性)

TCP是面向连接就是与它的三次握手相关:

在这里插入图片描述

上图是三次握手和四次挥手的图解

SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束)

1.2.1 为什么要三次握手?

第一次"握手" : 客户端给服务端发送消息(SYN数据包),说明自己想要与服务端(Tomcat等)建立连接;

第二次"握手" : 服务端接到客户端的消息(SYN数据包),开始发送确认数据包(ACK),并发送一个建立连接的数据包(SYN)给客户端,建立廉价而

第三次"握手" : 客户端接收到服务端的消息(数据包),发送最后一个确认数据包给服务端,完成三次"握手",建立连接;

注意:

1 其实建立连接实质上就是客户端和服务端分别创建一个buffer数据缓冲区来给处理彼此的数据,两个buffer都各自存在对方想要的数据,就证明已经建立连接;

2 三次握不仅证明TCP是面向连接的,也说明了TCP的可靠性;

1.3 TCP的四次挥手

注意:

1 通过上面的图可以看出,其实再四次挥手之前客户端和服务端已经完成了数据的传输;

2 进行数据的传输其实TCP是通过Socket来完成的;

1.3.1 Socket

TCP底层是如何通过Socket来完成连接和数据的传输的呢?

  Socket在建立连接时需要客户端和服务端各自提供一个IP:PORT  来组成一个四元组

​ 这样TCP建立连接之后,就能进行数据的读取和发送;

Socket我们称之为  插座 或者 套接字  
其实就是客户端和服务端分别提供IP和端口号建立连接完成传输控制层的数据交互的;
四元组是对插座和套接字最完美的描述.
1.3.2 为什么要进行四次挥手?

因为客户端和服务端数据发送结束之后,为了不占用双方端口号,就需要进行断开连接;

四次挥手:

客户端: 发送一个断开连接的FIN数据包给服务端;

服务端: 收到客户端的数据包之后,发送一个ACK确认数据包给客户端;此时客户端收到这个包之后还在等待;

服务端: 接着又一次发送一个FIN数据包给客户端,告诉对方,断开连接;

客户端: 收到服务端的断开连接数据包,发送一个确认数据包(ACK)给服务端,真正断开连接;

注意:

断开连接之后各自的IP和端口号也不再占用,这样就释放了;

1.4 小结

1 通过上面可以看出每一次HTTP请求必将经过三次握手和四次挥手;

2 每一次连接断开之后并没有对数据进行缓存以及事务操作,所以这也是HTTP协议"无状态"的一种体现,不去缓存请求数据,想要获取需要再次建立一次连接;(这里的缓存不是指浏览器,二十Socket建立连接开辟的buffer)

3 TCP建立连接不是我们的浏览器负责完成的,是我们操作系统负责建立连接(因为我们操作系统默认有建立连接的方法,这也是操作系统最基本的功能,所以浏览器直接调用操作系统的建立TCP连接的功能即可):
步骤如下:
​ 1 浏览器通过发送HTTP协议构造我们要发送数据和接收的数据;

​ 2 调用OS(操作系统)的建立TCP连接的方法,建立TCP连接;

​ 3 通过TCP发送数据;

2 HTTP请求

2.1 HTTP请求的格式

下图是:HTTP请求的基本消息格式

在这里插入图片描述

上图可以看出:

HTTP请求的消息格式: 请求行 请求头 请求空行 请求体(只针对与post请求)

2.2 HTTP请求的方法

HTTP请求的方法截图如下:

在这里插入图片描述

我们常用的请求方法就是get和post ;

head 请求方法与get请求的区别就在于,head只是用于确定请求是不是发出去了,是不是发送成功了;它不会返回数据给我们;

3 HTTP响应

3.1 HTTP 响应的格式

HTTP响应格式如下图:

在这里插入图片描述

HTTP的响应是由: 状态行 响应头 响应空行 响应正文组成的

3.2 HTTP状态码

为什么要将状态码放到HTTP响应中进行介绍呢?

因为状态码其实是服务器告诉浏览器是否请求成功,以及如何解析资源的"暗号";(具体可以参考Servlet简记***这篇文章)

在这里插入图片描述

注意: 下面是开发中常见的状态码

100 表示 请求已发出,还需要继续请求获取数据

200 代表成功

301 永久重定向 请求的资源被永久移动到新的URL

302 临时重定向 资源被临时移动,客户端继续使用原有的URL

304 未修改 返回此状态码证明请求的资源没有被修改,这是因为浏览器(这里以谷歌为例)会对第一次的请求的资源进行缓存,第二次没有断开浏览器继续请求,请求的资源没有修改,就会返回304状态码,不返回200;

404 找不到请求资源

500 服务器内部出现错误;

4 HTTP长连接和短链接

本章内容为TCP底层原理,是对HTTP协议的扩展

4.1 什么是长连接和短链接

长连接和短链接其实从实质上将就是当一次HTTP请求过来之后,如果一个请求结束立刻断开Socket连接就是短连接,如果没有立刻断开,其他请求还能继续使用该socket连接传输数据就时长连接;

其实从实际原理上将,说HTTP的长连接和短链接是不合理的,其实应该说是TCP的长连接和短链接才相对合理;

原因:

其实上面已经说过了,HTTP协议是应用层的协议,真正建立连接和传输通信的是传输控制层,也就是TCP协议负责,而TCP又是通过Socket进行连接的,所以可以知道长连接和短链接其实底层是基于Socket实现的;

注意事项:

在HTTP1.0 时浏览器默认使用的都是短链接;

在HTTP1.1 就开始默认使用的长连接的方式了;

4.2 长连接和短链接的请求/响应头

在HTTP想要通过TCP传输控制层去建立长连接或者短连接时会发送一个请求头

connection : close --短链接请求头

connection: keep-alive --长连接请求头

通过浏览器截图来简单看一下:

下图可以看到在响应头和请求头中各自都有一个connection的请求头,可以看到他们都是keep-alive

这就是一个长连接;

在这里插入图片描述

4.3 短链接

4.3.1 短链接图解

下面通过画图的形式理解短连接是如何实现的:

在这里插入图片描述

4.3.2 短连接注意事项

从上面的图解可以看到,浏览器每一次请求,TCP都会建立一次连接,数据请求结束和响应结束,连接就会断开

1 一般短连接断开连接都是Client收到服务端的响应头信息中的connection:close之后就会断开连接;

2 优点: 短连接的每一次请求都是有效的连接,不需要额外的控制手段;

4.4 长连接

4.4.1 长连接图解

下图为长连接图解

在这里插入图片描述

解释:

上图中可以看出:客户都安和服务端通过Socket建立连接,客户端发送请求的时候会发送一个请求头

connection : keep-alive 服务端收到这个请求头之后会去判断MaxKeepAliveRequests是不是达到了默认值(没有修改此值),达到了就会响应给客户端connection:close 断开Socket连接,如果没有达到就继续保持Socket连接状态,这样其他请求来了就可以再次利用该Socket传递数据;直到已经到了该MaxKeepAliveRequests就会发送

connection:close 给客户端两者断开连接;

注意以上只针对于长连接来说的

对于KeepaliveTimeout 这个参数其实就是限制了该长连接保持多久,也就是当第一个请求结束后,Socket等待下一个请求过来的时间,如果超过了这个时间此Socket也会断开连接

4.4.2 长连接注意事项

1 HTTP1.1之后默认是长连接;

2 MaxKeepAliveRequests 和 KeepaliveTimeout 两个参数是Tomcat中的两个参数;

3 如果设置MaxKeepAliveRequests =1 其实是等于仅用了Tomcat的长连接,当MaxKeepAliveRequests 设置为<0的数字之后客户端发送的长连接请求数将没有限制; 不过Tomcat中MaxKeepAliveRequests 默认为100

5 浏览器小结

我们知道HTTP请求是通过客户端发送的,更多的时候是我们的浏览器发出的;

而且客户端和服务端都需要提供通过Socket进行连接和数据通信;

值得注意的是谷歌浏览器最多只支持并发6个Socket连接,也就是它发送请求一次最多可以和服务端建立6个Socket连接,那么也就证明了,当长连接时候,我们的Socket是可以被不同的请求共用来传递数据的;

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

liu.kai

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值