Http协议

request

GET /mix/76.html?name=kelvin&password=123456 HTTP/1.1//请求类型 要访问的资源 协议版本
Host: www.fishbay.cn //目的地 主机域名
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 //客户端信息
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 //可以接受的数据类型
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6

response

HTTP/1.1 200 OK //版本号 状态码 状态消息
Server: nginx
Date: Mon, 20 Feb 2017 09:13:59 GMT
Content-Type: text/plain;charset=UTF-8 //body类型
Vary: Accept-Encoding
Cache-Control: no-store //是否缓存

从输入 URL 到页面加载发生了什么?

1. 浏览器查找域名的ip地址（可以通过浏览器缓存，路由器缓存，DNS缓存）使用DNS协议获取域名对应的IP
2. 浏览器向远程web服务器发送一个HTTP请求（cookie也会随着请求发送给服务端）（2-4的过程中，会使用TCP协议，与服务器建立TCP连接，建立TCP连接需要发送数据，发送数据在网络层使用IP协议.IP数据报在路由器之间，路由选择使用OPSF协议，路由器在与服务器通信时，需要将ip地址转换为MAC地址，使用ARP协议）
3. 服务器处理请求，根据传过来的参数，cookie信息生成一个HTML响应
4. 服务器返回一个响应
5. 浏览器解析并渲染页面（TCP建立以后，使用HTTP协议来访问网页）
6. 结束链接

常见的状态码：
1XX：接受的请求正在处理

2XX：请求正常处理完毕

3XX：重定向状态码

4XX：客户端错误，服务器无法处理请求

5XX：服务器错误，服务器处理请求出错

具体的：

200：服务器成功处理了请求，并且提供了请求的网页

201：请求成功并且服务器创建了新的资源，一般是数据库操作成功，新建修改

202： 服务器已接受请求，但尚未处理。（异步任务进入排队）

204：一般是删除数据成功。

300（多种选择） 针对请求，服务器可执行多种操作。

301：（永久移动）

    1.被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可 能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
	
	2.新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
	
	3.如果这不是一个 GET 或者 HEAD 请求，浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。
	**注意**：对于某些使用 HTTP/1.0 协议的浏览器，当它们发送的 POST 请求得到了一个301响应的话，接下来的重定向

请求将会变成 GET 方式。

302：（临时移动）

1.HTTP1.0的状态码，HTTP1.1也有保留。
2.如果client向server发送post请求。server返回URL和302。
3.如果用户确认，client发送post请求。（但实际情况是，很多浏览器都不问问用户，直接变为get,发送get请求）

303(http1.1新增)：

1.HTTP1.1的状态码
2.发送Post请求，收到303，直接重定向为get，发送get请求，不需要向用户确认

304:

1.如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。
2/该响应必须包含以下的头信息：
	Date，除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则，那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去（正如RFC 2068中规定的一样），缓存机制将会正常工作。
	ETag 和/或 Content-Location，假如同样的请求本应返回200响应。Expires, Cache-Control，和/或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。假如本响应请求使用了强缓存验证，那么本次响应不应该包含其他实体头；否则（例如，某个带条件的 GET 请求使用

了弱缓存验证），本次响应禁止包含其他实体头；这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。假如某个304响应指明了当前某个实体没有缓存，那么缓存系统必须忽视这个响应，并且重复发送不包含限制条件的请
求。假如接收到一个要求更新某个缓存条目的304响应，那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段
的值。

307:

1.HTTP1.1的状态码
2.客户端发送post请求返回307时，浏览器询问用户是否再次post

400：（错误请求） 服务器不理解请求的语法。

401：（未授权） 请求要求用户的身份验证。对于登录后请求的网页，服务器可能返回此响应。

403：（禁止） 服务器拒绝请求。（偶然看到了这个报错403，是当时我们链接地址是https://www.ceshi.com; 但是却被谁谁谁配置成了http://www.ceshi.com;最后就会导致。403的报错。解决办法：就是将http改成https。）

404：（未找到）
服务器找不到请求的网页。例如，对于服务器上不存在的网页经常会返回此代码。

408（请求超时） 服务器等候请求时发生超时。

500（服务器内部错误） 服务器遇到错误，无法完成请求。

RPC和Rest协议：
Rest：严格意义上说接口很规范，操作对象即为资源，对资源的四种操作（post、get、put、delete），并且参数都放在URL上,但是不严格的说Http+json、Http+xml，常见的http api都可以称为Rest接口。

RPC:我们常说的远程方法调用，就像调用本地方法一样调用远程方法，通信协议大多采用二进制方式。

RPC框架的职责是： 让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

几种协议：
Socket使用时可以指定协议Tcp,Udp等；

RIM使用Jrmp协议，Jrmp又是基于TCP/IP；

RPC底层使用Socket接口，定义了一套远程调用方法；

HTTP是建立在TCP上，不是使用Socket接口，需要连接方主动发数据给服务器，服务器无法主动发数据个客户端；

http 1.1 与 http 1.0 的区别？

1. http 1.0 对于每个连接都得建立一次连接, 一次只能传送一个请求和响应, 请求就会关闭, http1.0 没有 Host 字段
2. 而 http1.1 在同一个连接中可以传送多个请求和响应, 多个请求可以重叠和同时进行, http1.1 必须有 host 字段
3. http1.1 中引入了 ETag 头, 它的值 entity tag 可以用来唯一的描述一个资源. 请求消息中可以使用 If-None-Match 头域来匹配资源的 entitytag 是否有变化
4. http1.1 新增了 Cache-Control 头域(消息请求和响应请求都可以使用), 它支持一个可扩展的指令子集
5. http1.0 中只定义了 16 个状态响应码, 对错误或警告的提示不够具体. http1.1 引入了一个 Warning 头域, 增加对错误或警告信息的描述. 且新增了 24 个状态响应码

TCP 三次握手和四次挥手
建立 TCP 连接需要三次握手：
三次握手: 首先 Client 端发送连接请求报文，Server端接受连接后回复 ACK 报文，并为这次连接分配资源。Client 端接收到 ACK 报文后也向 Server 段发生 ACK 报文，并分配资源，这样 TCP 连接就建立了。

6. 客户机的 TCP 先向服务器的 TCP 发送一个连接请求报文. 这个特殊的报文中不含应用层数据, 其首部中的 SYN 标志位被置 1. 另外, 客户机会随机选择一个起始序号 seq=x(连接请求报文不携带数据,但要消耗掉一个序号)
7. 服务器端的 TCP 收到连接请求报文后, 若同意建立连接, 就向客户机发送请求, 并为该 TCP 连接分配 TCP 缓存和变量. 在确认报文中,SYN 和 ACK 位都被置为 1, 确认号字段的值为 x+1, 并且服务器随机产生起始序号 seq=y(确认报文不携带数据, 但也要消耗掉一个序号). 确认报文同样不包含应用层数据.
8. 当客户机收到确认报文后, 还要向服务器给出确认, 并且也要给该连接分配缓存和变量. 这个报文的 ACK 标志位被置为 1, 序号字段为 x+1, 确认号字段为 y+1.

四次挥手 :

1. 客户机打算关闭连接,就向其 TCP 发送一个连接释放报文,并停止再发送数据,主动关闭 TCP 连接, 该报文的 FIN 标志位被置 1, seq=u, 它等于前面已经传送过的数据的最后一个字节的序号加 1(FIN 报文即使不携带数据,也要消耗掉一个序号)
2. 服务器接收连接释放报文后即发出确认, 确认号是 ack=u+1, 这个报文自己的序号是 v, 等于它前面已传送过的数据的最后一个自己的序号加 1. 此时, 从客户机到服务器这个方向的连接就释放了, TCP 连接处于半关闭状态. 但服务器若发送数据, 客户机仍要接收, 即从服务器到客户机的连接仍未关闭.
3. 若服务器已经没有了要向客户机发送的数据, 就通知 TCP 释放连接, 此时其发出 FIN=1 的连接释放报文
4. 客户机收到连接释放报文后, 必须发出确认. 在确认报文中, ACK 字段被置为 1, 确认号 ack=w+1, 序号 seq=u+1. 此时, TCP 连接还没有释放掉, 必须经过等待计时器设置的时间 2MSL 后, A 才进入到连接关闭状态.

运输层
运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

运输层主要使用以下两种协议

1. 传输控制协议 TCP（Transmisson Control Protocol）–提供面向连接的，可靠的数据传输服务。
2. 用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

TCP 的主要特点

3. TCP 是面向连接的。（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）
4. 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）；
5. TCP 提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复、并且按序到达；
6. TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；
7. 面向字节流。TCP 中的“流”（Stream）指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

UDP 的主要特点
8. UDP 是无连接的；
9. UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）；
10. UDP 是面向报文的；
11. UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 直播，实时视频会议等）；
12. UDP 支持一对一、一对多、多对一和多对多的交互通信；
13. UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

TCP 协议如何来保证传输的可靠性?
TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。
对于可靠性，TCP 通过以下方式进行保证：
14. 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
15. 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
16. 丢弃重复数据：对于重复数据，能够丢弃重复数据；
17. 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
18. 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
19. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

Http 和 Https 的区别?

1. Http 协议运行在 TCP 之上，明文传输，客户端与服务器端都无法验证对方的身份；Https 是身披 SSL(Secure Socket Layer)外壳的 Http，运行于 SSL 上，SSL 运行于 TCP 之上，是添加了加密和认证机制的 HTTP。
2. 端口不同：Http 与 Http 使用不同的连接方式，用的端口也不一样，前者是 80，后者是 443；
3. 资源消耗：和 HTTP 通信相比，Https 通信会由于加减密处理消耗更多的 CPU 和内存资源；
4. 开销：Https 通信需要证书，而证书一般需要向认证机构购买；
5. Https 的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

Http 2.0 与 http1.x 相比有什么优点?

1. 二进制格式:http1.x 是文本协议，而 http2.0 是二进制以帧为基本单位，是一个二进制协议，一帧中除了包含数据外同时还包含该帧的标识：Stream Identifier，即标识了该帧属于哪个 request,使得网络传输变得十分灵活。

2. 多路复用: 一个很大的改进，原先 http1.x 一个连接一个请求的情况有比较大的局限性，也引发了很多问题，如建立多个连接的消耗以及效率问题。
   (1) http1.x 为了解决效率问题，可能会尽量多的发起并发的请求去加载资源，然而浏览器对于同一域名下的并发请求有限制，而优化的手段一般是将请求的资源放到不同的域名下来突破这种限制。
   (2) http2.0 支持的多路复用可以很好的解决这个问题，多个请求共用一个 TCP 连接，多个请求可以同时在这个 TCP 连接上并发，一个是解决了建立多个 TCP 连接的消耗问题，一个也解决了效率的问题。那么是什么原理支撑多个请求可以在一个 TCP 连接上并发呢？基本原理就是上面的二进制分帧，因为每一帧都有一个身份标识，所以多个请求的不同帧可以并发的无序发送出去，在服务端会根据每一帧的身份标识，将其整理到对应的 request 中。

3. header 头部压缩:主要是通过压缩 header 来减少请求的大小，减少流量消耗，提高效率。因为之前存在一个问题是，每次请求都要带上 header，而这个 header 中的数据通常是一层不变的。

4. 支持服务端推送