（二）图解Http笔记

1.Http协议

Http协议:对器客户端和服务器端之间数据传输的格式规范，格式简称为“超文本传输协议”。

2.网络基础 TCP/IP

通常使用的网络（包括互联网）是在 TCP/IP 协议族的基础上运作的。而 HTTP 属于它内部的一个子集。

2.1TCP/IP 的分层管理

应用层：决定了向用户提供应用服务时的通信活动，如FTP，DNS和HTTP等；

传输层：提供处于网络连接中的两台计算机之间的数据传输，TCP，UDP；

网络层（又名网络互连层）：用来处理网络上流动的数据包，IP协议；

链路层（又名数据链路层，网络接口层）：网络连接的硬件部分。

数据在各层中封装后进行传输如下图：

2.2IP

IP协议的作用是把各种数据包传送给接收方，其中IP地址和MAC（网卡所属的固定地址，基本上不会更改）地址用于确定接收方的位置。IP地址可以通过ARP协议（Adress Resolution Protocol）反查出对应的MAC地址

2.3TCP 协议

TCP协议能够将数据准确可靠地传输给接收方，采用了三次握手 （three-way handshaking）策略

握手过程中使用了 TCP 的标志（flag） —— SYN（synchronize）和ACK（acknowledgement）。

发送端首先发送一个带 SYN 标志的数据包给对方。

接收端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。

最后，发送端再回传一个带 ACK 标志的数据包，代表“握手”结束。

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

2.3DNS服务

DNS(Domain Name System)服务是和 HTTP 协议一样位于应用层的协议。它提供域名到 IP 地址之间的解析服务。

2.4URI 和 URL

URL（Uniform Resource Locator，统一资源定位符）。

URI 是 Uniform Resource Identifier 的缩写（统一资源标识符）。

URI 就是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。

URI 用字符串标识某一互联网资源，而 URL表示资源的地点（互联网上所处的位置）。可见 URL是 URI 的子集。

总的来说：URI 是用一个字符串来表示互联网上的某一个资源。而 URL 表示资源的地点（互联网所在的位置）

2.5URI 格式

3.数据传输过程的流量控制和确认机制

建立可靠连接以后，就开始进行数据传输了。在通信过程中，最重要的是数据包，也就是协议传输的数据。如果数据的传送与接收过程当中出现收方来不及接收的情况，这时就需要对发方进行控制以免数据丢失。利用滑动窗口机制可以很方便的在 TCP 连接上实现对发送方的流量控制。TCP 的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

3.1滑动窗口协议

滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题；发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。

简单解释下，发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，而导致溢出，同时控制流量也可以避免网络拥塞。下面图中的 4,5,6 号数据帧已经被发送出去，但是未收到关联的 ACK，7,8,9 帧则是等待发送。可以看出发送端的窗口大小为 6，这是由接受端告知的。此时如果发送端收到 4 号 ACK，则窗口的左边缘向右收缩，窗口的右边缘则向右扩展，此时窗口就向前“滑动了”，即数据帧 10 也可以被发送。

发送窗口 :发送端允许连续发送的幀的序号表。发送端可以不等待应答而连续发送的最大幀数称为发送窗口的尺寸。

接收窗口:接收方允许接收的幀的序号表，凡落在接收窗口内的幀，接收方都必须处理，落在接收窗口外的幀被丢弃。接收方每次允许接收的幀数称为接收窗口的尺寸。

在线滑动窗口演示功能

4.简单的 HTTP 协议

HTTP 协议和 TCP/IP 协议族内的其他众多的协议相同，用于客户端和服务器之间的通信。（无状态协议）

4.1持久连接节省通信量（三次握手，四次挥手）

HTTP 协议的初始版本中，每进行一次 HTTP 通信就要断开一次 TCP 连接。（增加通信量的开销

为解决上述 TCP 连接的问题，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTPconnection reuse）的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

在持久连接基础上可以实现管线化，可以同时发送多个请求。

4.2使用 Cookie 的状态管理

HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。

优点：由于不必保存状态，自然可减少服务器的 CPU 及内存资源的消耗

Cookie 会根据从服务器端发送的响应报文内的一个叫做Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。

服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

5. HTTP 报文内的 HTTP 信息

5.1报文信息

客户端的Htpp报文叫做请求报文，服务器端的Http报文叫响应报文，报文使用CR+LF作为换行符。

报文分为报文首部和报文主体,报文首部一般有四种：通用首部，请求首部，响应首部和实体首部；在客户端与服务器之间进行通信过程中，无论是请求首部还是响应首部都能起到传递额外重要信息的作用，如报文主体大小，所使用的的语言和认证信息等

请求报文和响应报文的首部内容由以下数据组成。现在出现的各种首部字段及状态码稍后会进行阐述。

请求行：包含用于请求的方法，请求 URI 和 HTTP 版本。

状态行：包含表明响应结果的状态码，原因短语和 HTTP 版本。

首部字段：包含表示请求和响应的各种条件和属性的各类首部。

一般有 4 种首部，分别是：通用首部、请求首部、响应首部和实体首部。

其他：可能包含HTTP 的 RFC 里未定义的首部（Cookie 等）。