HTTP协议（包括Tcp三次握手、网络请求、）

HTTP协议
TCP三次握手
HTTP请求注意事项
HTTP服务
GET /POST请求的区别

HTTP简介

1.http协议介绍

1. HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网应用上最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。
2. HTTP是基于TCP/IP通信协议来传递数据的（HTML文件，图片文件，查询结果等）。
3. HTTP协议通常承载于TCP协议之上，有时也承载于TLS和SSL协议层之上，这个时候就成了我们常说的HTTPS。
4. HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。
5. HTTP默认端口号为80，HTTPS的端口号为443。

2.Http协议工作流程

一次HTTP操作称为一个事务，其工作过程大概如下

1. 用户在浏览器中键入需要访问网页的URL或者点击某个网页中的链接。
2. 浏览器根据URL中的域名，通过DNS解析出目标网页的IP地址。
3. 在HTTP开始工作之前，客户端首先会通过TCP/IP协议来和服务端建立连接（TCP三次握手）。
4. 建立连接后，客户端发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户端信息和内容。
5. 服务器接收到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后面是MIME信息包括服务器信息、实体信息和可能的内容。
6. 一般情况下，一旦Web服务器向浏览器发送了请求数据，他就要关闭TCP连接，然后如果浏览器或者服务器在其信息头加入这行代码：Connection:keep-alive,TCP 连接在发送后将仍然保持打开状态，于是浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

注意事项：
1.DNS域名解析采用的是递归查询的方式，过程是，先去找DNS缓存>缓存找不到就去找根域名服务器>根域名又会去找下一级>递归查找之后，找到了，给web浏览器。

2.为什么HTTP协议要基于TCP来实现？ TCP是一个端到端的可靠的面向连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）。

3.最后一步浏览器是如何对页面进行渲染的？

a）解析html文件构成 DOM树；

b）解析CSS文件构成渲染树；

c）边解析，边渲染 ；

d）JS 单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载；

2.1 短连接

短连接的操作步骤是：建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接…

如果客户请求频繁，将在TCP的建立和关闭操作上浪费较多的时间和带宽。

2.2 长连接

长连接，指的是在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。

长连接的操作步骤：建立连接——数据传输…(保持连接)…数据传输——关闭连接。

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。

2.3 HTTP管线化

HTTP管线化是将多个HTTP请求整批提交的技术，而在传送过程中不需先等待服务器的回应。管线化机制须通过永久连接完成，并且只有GET和HEAD要求可以进行管线化

2.4 部分内容解释

2.4.1.TCP 三次握手

为什么建立连接需要三次握手？

首先非常明确的是两次握手是最基本的。第一次握手，客户端发了个连接请求消息到服务器端，服务端收到消息后知道自己与客户端是可以连接成功的，但此时客户端并不知道服务端是否已经接收到了它的请求，所以服务端接收到消息后的应答，客户端得到服务端的反馈才确定自己与服务端是可以连接上的，这是第二次握手。

客户端只有确定了自己能与服务端连接上才能开始发数据，所以两次握手是最基本的。

综上我们思考一下，如果没有第三次握手，而是两次握手之后就认为连接成功了，那么会发生什么呢？第三次握手是为了防止已经失效的连接请求报文突然又传到服务端，因而产生错误。

例如发起请求时发生这样的状况：客户端发出去的第一个连接请求由于某些原因呢在网络节点中滞留了导致延迟，直到连接释放的某个时间点才到达服务端，这是一个失效的报文，但是此时服务端仍然认为这是客户端的建立连接请求的第一次握手，于是服务端回应了客户端，第二次握手。

如果只有两次握手，那么到这里，连接就已经建立成功了。但是此时客户端并没有任何数据要发送，而服务器还在傻傻的等候佳音，造成很大的资源浪费。所以需要三次握手，只有客户端再次回应一下，就可以避免这种状况。

生活场景实例：
你首先向妹子招手(syn)，妹子看到你向自己招手后，向你点了点头挤出了一个微笑(ack)。你看到妹子微笑后确认了妹子成功辨认出了自己(进入estalished状态)。
但是妹子有点不好意思，向四周看了一看，有没有可能你是在看别人呢，她也需要确认一下。妹子也向你招了招手(syn)，你看到妹子向自己招手后知道对方是在寻求自己的确认，于是也点了点头挤出了微笑(ack)，妹子看到对方的微笑后确认了你就是在向自己打招呼(进入established状态)。

我们来回顾一下，这个过程中总共有四个动作，

你招手
妹子点头微笑
妹子招手
你点头微笑

其中妹子连续进行了两个动作，先是点头微笑(回复对方)，然后再次招手(寻求确认)，实际上我们可以将这两个动作合成一个动作，招手的同时点头和微笑(syn+ack)。于是这四个动作就简化成了三个动作。

你招手
妹子点头微笑并招手
你点头微笑

这就是三次握手的本质，中间的一次动作是两个动作的合并。通过这个案例，不知你对TCP三次握手，有没有进一步的理解。

握手完成后，开始TCP数据传输：

TCP数据传输就是两个人隔空进行交流，有一定的距离，需要对方反复确认听见了自己的话。

你喊了一句对话(data)，妹子听见了之后要向你回复自己听见了(ack)。如果你喊了一句，半天没听到妹子回复，你会很低落，你不甘心，所以一次不行就两次，两次不行就三次，这就是tcp重传。

既然会重传，妹子就可能一句话听见了两次，这就是去重，重新换和去重这两项工作操作系统的网络内核模块都已经帮我们处理好了，我们不用理会。

三次握手防止丢包、乱序、

2.4.2.操作事务实例

在我们查看某个发送请求给后端同学并响应结果的时候，我们可以点击这个接口名称，右方会出现Headers、Preview、Response、Initiator、Timing。

2.4.2.1 Headers

这里就是所谓的请求头，包括general header、request header、response header、entity header几部分。

General

• Request URL:客户端的请求地址，对应服务端的服务。
• Request Method：请求类型，主要有get、post、put、delete等一系列，最常用的还是get、post
• Status Code：响应状态码，可以在这里看常用状态码及解释
• Remote Address：域名对应的ip及端口，这个直接显示当前请求是请求的那个ip的服务，用于定位异常服务很有用。
• Referrer Policy:Referrer的策略，即Referrer属性可返回载入当前文档的URL。Referrer策略

3.HTTP请求报文

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：

1. 请求行（Request line）
2. 请求头部（Header）
3. 请求体

3.1 请求行

1.方法：
	GET 获取资源
	POST 向服务器发送数据，传输实体主体
	PUT 传输文件
	HEAD 获取报文首部
	DELETE 删除文件
	OPTIONS 询问支持的方法
	TRACE 追踪路径
2.协议/版本号
3.URL

3.2 请求头

1. 通用头部（General Header）
2. 请求首部（Request Header）
3. 响应首部（Response Header）
4. 实体首部（Entity Header Fields）

3.2.1通用首部字段

Cache-Control 控制缓存行为
Connection 链接的管理
Date 报文日期
Pragma 报文指令
Trailer 报文尾部的首部
Trasfer-Encoding 指定报文主体的传输编码方式
Upgrade 升级为其他协议
Via 代理服务器信息
Warning 错误通知

3.2.2 请求首部字段

首部字段名 说明
Accept 用户代理可处理的媒体类型
Accept-Charset 优先的字符集
Accept-Encoding 优先的编码
Accept-Langulage 优先的语言
Authorization Web认证信息
Expect 期待服务器的特定行为
From 用户的电子邮箱地址
Host 请求资源所在的服务器
If-Match 比较实体标记
If-Modified-Since 比较资源的更新时间
If-None-Match 比较实体标记
If-Range 资源未更新时发送实体Byte的范围请求
If-Unmodified-Since 比较资源的更新时间(和If-Modified-Since相反)
Max-Forwards 最大传输跳数
Proxy-Authorization 代理服务器需要客户端认证
Range 实体字节范围请求
Referer 请求中的URI的原始获取方
TE 传输编码的优先级
User-Agent HTTP客户端程序的信息

3.3.3 响应首部字段

Accept-Ranges 是否接受字节范围
Age 资源的创建时间
ETag 资源的匹配信息
Location 客户端重定向至指定的URI
Proxy-Authenticate 代理服务器对客户端的认证信息
Retry-After 再次发送请求的时机
Server 服务器的信息
Vary 代理服务器缓存的管理信息
www-Authenticate 服务器对客户端的认证

3.3.4 实体首部字段

Allow 资源可支持的HTTP方法
Content-Encoding 实体的编码方式
Content-Language 实体的自然语言
Content-Length 实体的内容大小(字节为单位)
Content-Location 替代对应资源的URI
Content-MD5 实体的报文摘要
Content-Range 实体的位置范围
Content-Type 实体主体的媒体类型
Expires 实体过期时间
Last-Modified 资源的最后修改时间

3.3 GET请求与POST请求的区别

1. GET把参数直接包含在URL中，明文传输。POST通过Request body传递参数
2. GET在浏览器回退时是无害的，而POST会再次提交请求
3. GET产生的URL地址可以被Bookmark书签记载，而POST不可以
4. GET请求会被浏览器主动缓存，而POST不会，除非主动设置
5. GET请求只能进行url编码，而POST支持多种编码方式
6. GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留
7. GET请求在URL中传送的参数是有长度大小限制的，而POST没有
8. 对参数的数据类型，GET只接受ASCII字符，而POST没有限制
9. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息

1. GET和POST是HTTP请求中的两种方法
2. HTTP是基于TCP/IP的关于数据如何在万维网中通信的协议
3. HTTP的底层是TCP/IP。所以GET、POST的底层也是TCP/IP，也就是说GET、POST都是TCP链接。GET和POST能做的事情是一样的，如果你给GET增加request body，给POST带上url参数，技术上是完全可行的。
4. GET产生一个TCP数据包，POST产生两个TCP数据包，对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。因为POST需要两步，时间上的消耗会更多一些，看起来GET比POST更有效，但是GET和POST都有自己的语义，不能随便混用。在网络环境好的情况下，发一次包和两次包的时间差别基本可以无视，而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

4.http中重定向和请求转发的区别

解释一：转发是服务器行为，重定向是客户端行为。

4.1 转发过程

客户端浏览器发送http请求 ——> web服务器接收此请求 ——> 调用内部的一个方法在容器内部完成请求处理和转发动作 ——>将目标资源发送给客户。在这里，转发的路径必须是同一个web容器下的url，不能转到其他的web路径上去，中间传递的是自己容器内的request。在客户浏览器路径栏显示的还是其第一次访问的路径，也就是客户是感觉不到服务器做了转发的，转发行为是浏览器只做了一次访问请求。

4.2 重定向过程

客户端浏览器发送HTTP请求——> web服务器接收后发送302状态码相应及对应新的location给客户端浏览器——>客户端浏览器发现是一个302响应，则自动发送一个新的http请求，请求url是新的location地址——>服务器根据此请求寻找资源并发送给客户。在这里location可以重定向至任意URL，既然是浏览器重新发送出了请求，则没有什么request传递的概念了。在客户端浏览器显示的是其重定向后的路径，客户端是可以观察到地址变化的。重定向行为是浏览器做了至少两次访问请求的。

解释二：request不同

4.1 重定向

重定向，其实是两次request。第一次，客户端request A，服务器端响应，并response回来，告诉浏览器，你应该去B，这个时候可以看到地址栏发生变化，而且历史的回退按钮也可以点击状态。重定向可以访问自己web应用以外的资源。在重定向的过程中，传输的信息会被丢失。

4.2 转发

请求转发是服务器内部把对一个request/response的处理权，交给了另一个，对于客户端而言，他只知道自己最早请求那个A，而不知道中间的B，甚至C、D。传输的信息不会丢失。