6.主要协议（UDP、TCP、IP、HTTP）_ip、tcp、udp、http行业标准

一、IP地址

1.1 概念

 互联网上的每一个主机都有一个IP地址

IPv4版本：32bit（4字节）
IPv5版本：128bit（16字节）

默认版本是IPv4版本

按字节分，每一字节换算成十进制

1.2 IP地址的组成（按功能分）

IP地址由2部分组成：网络标识（网络ID）、主机标识（主机ID）

 同一网段的计算机，网络ID相同

 通过子网掩码（subnet mask）可以计算出网络ID：子网掩码 &（按位与） IP地址

 子网掩码的作用一般用来计算网段

 按位与：和1按位与，结果是原来值；和0按位与，结果是0

示例1：

示例2：

注：主机位不能为全0或全1

 所以此网段可容纳的设备为：256 * 256 - 2

计算机和其他计算机通信前，会先判断目标主机和自己是否在同一网段

 同一网段：不需要由路由器进行转发

 不同网段：交由路由器进行转发

1.3 IP地址的分类（了解）

只有A\B\C类地址才能分配给主机

 主机标识为全0，表示主机所在的网段
 主机标记为全1，表示主机所在网段的全部主机（广播）
  可以尝试用ping给某个网段的全部主机发数据

1.3.1 A类地址

网络ID：

 0不能用，127作为保留网段，其中127.0.0.1是本地环回地址（Loopback），代表本机地址

 可以分配给主机的

  第1部分的取值范围是：1~126

主机ID：

 第2、3、4部分的取值范围是：0~255

 每个A类网络能容纳的最大主机数是：256 * 256 * 256 - 2 = 2^24 - 2 = 16777214

1.3.2 B类地址

网络ID：

 最小：128.0；最大：191.255

 可以分配给主机

主机ID：

 每个B类网络能容纳的最大主机数是：256 * 256 - 2 = 2^16 - 2 = 65534

1.3.3 C类地址

1.3.4 D、E类地址

1.3.5 子网掩码的CIDR表示方法

CIDR：无类别域间路由

子网掩码的CIDR表示方法：

 192.168.1.100/24，代表子网掩码有24个1，也就是255.255.255.0

 123.210.100.200/16，代表子网掩码有16个1，也就是255.255.0.0

1.4 为什么要进行子网划分？

如果需要让200台主机在同一个网段内，可以分配一个C类网段，比如：192.168.1.0/24

 供254个可用IP地址：192.168.1.1 ~ 192.168.1.254

 多出54个空闲的IP地址，这种情况不算浪费资源

如果需要让500台主机在同一个网段内，那就分配一个B类网段，比如：191.100.0.0/16

 共65534个可用IP地址：191.100.0.1 ~ 191.100.255.254

 多出65034个空闲的IP地址，这种情况属于极大的浪费资源

如何尽量避免浪费IP地址资源？
 合理进行子网划分

1.4.1 等长子网划分

概念：借用主机位作子网位，划分出多个子网

可以分为：

 等长子网划分：将一个网段等分成多个子网，每个子网的可用IP地址数量是一样的

 变长子网划分：每个子网的可用IP地址数量可以是不一样的

子网划分步骤：

 确定鸽子王的子网掩码长度

 确定子网中第1个、最后1个主机可用的IP地址

1.4.2 等长子网划分–等分成2个子网

A子网可以容纳的主机数：0 ~ 126–126台

 IP地址为192.168.0.1 ~ 192.168.0.126

B子网可以容纳的主机数：129 ~ 254—126台

 IP地址为192.168.0.129 ~ 192.168.0.254

1.4.3 等长子网划分–等分成4个子网

A子网主机数：1 ~ 62–62台

B子网主机数：65 ~ 126

C子网主机数：129 ~ 190

D子网主机数：193 ~ 254

1.4.4 等长子网划分–等分成8个子网

广播地址为主机部分全为1

1.4.5 等长子网划分–等分成4个子网的广播地址

1.5 变长子网划分

如果一个子网地址快的长度是原网段的（1/2）^n，那么：

 子网的子网掩码就是在原网段的子网掩码基础上增加n个1

 不等长的子网，它们的子网掩码也不同

假设对192.168.0.0/24进行变长子网划分

思考题：

 这2台设备能正常通信么？

第一种计算方式：子网掩码 & IP地址 = 网段

左网段：192.168.0.0/24
右网段：192.168.0.0/16

不能通信，网络要通的话需要双方通信

1.6 超网

1.6.1 概念

 跟子网反过来，它是将多个连续的网段合并成一个更大的网段

1.6.2 合并2个网段–子网掩码左移1位

 需求：原本有200台计算机使用192.168.0.0/24网段，现在希望增加200台设备到同一网段

  200台在192.168.0.0/24网段，200台在192.168.1.0/24网段

  合并192.168.0.0/24、192.168.1.0/24为一个网段：192.168.0.0/23（子网掩码往左移动1位）

思考：

 192.168.0.255/23这个IP地址，可以分配给计算机使用吗？

192.168.0.255/24不能分配，是广播IP地址

所以，此地址可以分配给计算机使用

但是，192.168.1.255/23就不可以分配给计算机使用，是广播地址

1.6.3 合并4个网段–子网掩码左移2位

只有连续的网段才可以进行合并


思考：

 下面2个网段，能通过子网掩码向左移动1位进行合并吗？

 不可以，无法将192.168.2.0的网段包含进去

1.6.4 合并网段的规律

向左移动后，两个网段左边的网络号需要一致

1.6.5 判断一个网段是子网还是超网

首先，

 看该网段的类型，是A类网络、B类网络还是C类网络？

 默认情况下，A类子网掩码位数是8，B类是16，C类是24

如：192.168.10.10/22–C类网络左移2位，超网

191.168.10.10/18–B类网络右移2位，子网

1.7 IP地址的分配

IP地址按照分配方式，可以分为：静态IP地址、动态IP地址

静态IP地址：

 手动设置

 适用场景：不怎么挪动的台式机（如学校机房中的台式机）、服务器等

动态IP地址：

 从DHCP服务器自动获取IP地址

 适用场景：移动设备、无线设备等

二、传输层（Transport）

传输层有2个协议：

 TCP，传输控制协议

 UDP，用户数据报协议

2.1 TCP与UDP的区别

UDP应用于实时场景

2.2 UDP

2.2.1 UDP- 数据格式

UDP对应的值是17,0x11

UDP是无连接的，减少了建立和释放连接的开销

UDP尽最大能力交付，不保证可靠交付

 因此不需要维护一次复杂的参数，首部只有8个字节（TCP的首部至少20个字节）

UDP长度

 占16位，首部长度 + 数据长度

2.2.2 UDP - 检验和

检验和的计算内容：伪首部 + 首部 + 数据

 伪首部：尽在计算检验和时起作用，并不会传递给网络层

2.2.3 UDP - 端口（Port）

UDP首部中端口是占用2字节

 可以推测端口号的取值范围是：0 ~ 65535

客户端的源端口是临时开启的随机端口

防火墙可以设置开启\关闭某些端口来提高安全性

常用命令行：


 安装telnet：控制面板 - 程序 - 启用或关闭Windows功能 - 勾选“Telnet Client” - 确定

2.3 TCP

2.3.1 TCP - 数据格式

TCP首部长度最少是20个字节

数据偏移：

 占4位，取值范围是0x0101 ~ 0x1111（5 ~ 15）

 乘以4，得到的数值是首部长度

 首部长度是20 ~ 60字节

保留：

 占6位，目前全为0

2.3.2 TCP的几个要点

可靠传输

 在传输过程中，服务器会将数据分为几个包进行传输，如果其中一个包丢失，服务器会重新将丢失的包进行传输，保证客户端接收到的数据是完整的

流量控制

拥塞控制

连接管理

 建立连接

 释放连接

2.3.3 TCP - 小细节

有些资料中，TCP首部的保留（Reserverd）字段占3位，标志（Flags）字段占9位

 Wireshark也是如此

UDP首部中有一个16位的字段记录了整个UDP报文段的长度（首部 + 数据）

 但是，TCP首部中只有一个4位的字段记录TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度

分析：

 UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐

 TCP\UDP的数据长度，完全可以有IP数据包的首部推测出来

  传输层的数据长度 = 网络层的总长度 - 网络层的首部长度 - 传输层的首部长度

2.3.4 TCP - 检验和

跟UDP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据

 伪首部：占用12字节，尽在计算检验和时起作用，并不会传递给网络层

2.3.5 TCP - 标志位

URG（Urgent）-紧急位：

 当URG = 1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送

ACK（Acknowledgment）-回应：

 当ACK = 1时，确认号字段才有效。

PSH（Push）

RST（Reset）-重置：

 当RST = 1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接

SYN（Synchronization）-建立连接：

 当SYN = 1、ACK = 0时，表明这是一个建立连接的请求

 若对方同意建立连接，则回复SYN = 1，ACK = 1

三次握手：

FIN（Finish）-释放连接：

 当FIN = 1时，表明数据已经发送完毕，要求释放连接

2.3.6 TCP - 序号、确认号、窗口

序号：

 占4个字节

 首先，在传输过程中的每一个字节都会有一个编号

 在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号

确认号：

 占4字节

 在建立连接后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节编号

窗口：

 占2字节

 这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）

2.4 TCP-可靠传输

2.4.1 停止等待ARQ协议

ARQ–自动重传请求

2.4.2 改进做法 - 连续ARQ协议 + 滑动窗口协议

不足窗体大小：

如果接受窗口最多能接收4个包

 但发送方只发了2个包

接收方如何确定后面还有没有2个包？

 等待一定时间后没有第3个包

 就会返回确认收到2个包给发送方

思考：

为什么选择在传输层就将数据“大卸八块”分成多个短，而不是等到网络层再分片传递给数据链路层？

 因为可以提高重传的性能

 如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传

 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可

具体示例：

现在假设每一组数据是100字节，代表一个数据段的数据

每一组给一个编号

2.4.3 SACK（选择性确认）

在TCP通信过程中，如果发送序列中间某个数据包丢失（如1、2、3、4、5中的3丢失了）
TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3、4、5）
这样原来已经正确传输的分组也可能重复发送（如：4、5），降低了TCP性能

为了改善上述情况，发展出了SACK技术

 告诉发送方哪些数据丢失，哪些数据已提前收到

 使TCP只重新发送丢失的包（如3），不用发送后续所有的分组（如4、5）

SACK信息会放在TCP首部的选项部分

 Kind：占1字节。值为5代表这是SACK选项

 Length：占1字节，表明SACK选项一共占用多少字节

 Left Edge：占4字节，左边界

 Right Edge：占4字节，右边界

一对边界信息需要占用8字节，由于TCP首部的选项部分最多40字节，所以

 SACK选项最多携带4组边界信息

 SACK选项的最大占用字节数 = 4 * 8 + 2 = 34

疑问：

若有个包重传了N次还是失败，会一直持续重传到成功为止么？

 这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文（RST）断开TCP连接

2.5 TCP-流量控制

如果接收方的缓存区满了，发送方还在疯狂发送数据

 接收方只能把收到的数据包丢掉，大量的丢包会极大的浪费网络资源

 所以要进行流量控制

2.5.1 概念

什么是流量控制？

 让发送方的发送速率不要太快，让接收方来得及接收处理

原理：

 通过确认报文中窗口字段来控制发送方的发送速率

 发送方的发送窗口大小不能超过接收方给出的窗口大小

 当发送方收到接收窗口的大小为0时，发送方就会停止发送数据

2.5.2 特殊情况

特殊情况：

 一开始，接收方给发送方发送了0窗口的报文段

 后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了

 发送方的发送窗口一直为0，双方陷入僵局

解决方案：

 当发送方收到0窗口通知时，这是发送方停止发送报文

 并且同时开启一个定时器，隔一段时间就发送一个测试报文去询问接收方最新的窗口大小

 如果接收的窗口大小还是为0，则发送方再次刷新启动定时器

2.6 TCP - 拥塞控制

2.6.1 基本概念

拥塞控制：

 防止过多的数据注入到网络中

 避免网络中的路由器或链路过载

拥塞控制是一个全局性的过程

 涉及到所有主机和路由器

 以及与降低网络传输性能有关的所有因素

 是大家共同努力的结果

相比而言，流量控制是点对点通信的控制

几个缩写：

 MSS：每个段最大的数据部分大小—在建立连接时确定

 cwnd（congestion window）：拥塞窗口–根据网络情况而定

 rwnd（receive window）：接收窗口–接收方告诉发送方

 swnd（send window）：发送窗口

  swnd = min（cwnd，rwnd）

2.6.2 方法1–慢开始（slow start，慢启动）

cwnd的初始值较小，然后岁数据包被接受方确认（收到一个ACK）

cwnd就成倍增长（指数级）

2.6.3 方法2–拥塞避免（congestion avoidance）

ssthresh（slow start threshold）：慢开始阈值，cwnd达到阈值后，以线性方式增加

拥塞避免（加法增大）：拥塞窗口缓慢增大，以防止网络过早出现拥塞

乘法减小：只要网络出现拥塞，把ssthresh减半，同时，执行慢开始算法（cwnd恢复到初始值）

当网络出现频繁拥塞时，ssthresh值就下降的很快

2.6.4 方法3–快速重传（fast retransmit）

接收方：

 每收到一个失序的分组后就立即发出重复确认

 使发送方及时知道有分组没有到达

 而不要等待自己发送数据时才进行确认

发送方：

 只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段

 而不必继续等到重传计时器到期后再重传

2.6.5 方法4–快速恢复（fast recovery）

当发送方连续收到三个重复确认，就执行“乘法减小”算法，把ssthresh减半

 这是为了预防网络发生拥塞

由于发送方现在认为网络很可能没有发生拥塞

 因此，与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值

 于是把cwnd值设置为ssthresh减半后的数值

 然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大

快重传 +快恢复：

2.6.6 发送窗口的最大值

发送窗口的最大值：swnd = min（cwnd，rwnd）

 当rwnd < cwnd时，是接收方的接受能力限制发送窗口的最大值

 当cwnd > rwnd时，则是网络的拥塞限制发送窗口的最大值

2.7 TCP-序号、确认号

SYN–同步请求建立连接
ACK–回应

2.7.1 请求建立连接

2.7.2 响应过程

发送http请求前，需要先发送建立连接请求




紫色：客户端给服务器发送请求
蓝色：服务器给客户端发送请求




第N个包的序号：前面N-1个包的总长度 + 1

2.7.3 序号和确认号的相对值

序号：是想告诉对方，现在的包发送到哪了

ACK：我已经收到多少了，请接下来该发送哪一个

2.7.4 序号和确认号的原生值

客户端的初始序号将来用在客户端的序号与服务器的ACK中
服务器的初始序号将来用在服务器的序号与客户端的ACK中

二者之间的关系：

 原生值 - 初始值 = 相对值

2.8 TCP – 建立连接–3次握手

2.8.1 建立连接–状态解读

CLOSED：client处于关闭状态

LISTEN：server处于监听状态，等待client连接

SYN-RCVD：表示server接收到了SYN报文，当收到client的ACK报文后，他会进入到ESTABLISHED状态

SYN-SENT：表示client已发送到SYN报文，等待server的第2次握手

ESTABLISHED：表示连接已经建立

2.8.2 建立连接–前2次握手的特点

SYN都设置为1

数据部分的长度都为0

TCP头部的长度一般是32字节

 固定头部：20字节

 选项部分：12字节

双方会交换确认一些信息

 如：MSS、是否支持SACK、Window scale（窗口缩放系数）等

 这些数据都放在了TCP头部的选项部分中（12字节）

2.8.3 建立连接–疑问

为什么建立连接时，要进行3次握手？2次不行吗？

 主要目的：防止server端一直等待，浪费资源

如果建立连接只需要2次握手，可能会出现的情况

 假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放后的某个时间才到达server

 本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求

 于是，server就向client发出确认报文段，同意建立连接

 如果不采用3次握手，name只要server发出确认，新的连接就建立了

 由于现在client并没有真正想连接服务器的意愿，因此不会理理睬server的确认，也不会向server发送数据

 但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就被白白浪费掉

采用“三次握手”的办法可以防止上述现象的发生

 例如上述情况，client没有向server的确认发生确认，server由于收不到确认，就知道client并没有要求建立连接

第3次握手失败了，会怎么处理？

 此时server的状态SYN-RCVD，若等不到client的ACK，server会重新发送SYN + ACK包

 如果server多次重发SYN+ACK都等不到client的ACK，就会发送RET包，强制关闭连接

2.9 TCP–释放连接–4次挥手

2.9.1 释放连接–状态解读

FIN-WAIT-1：表示想主动关闭连接

 向对方发送了FIN报文，此时进入到FIN-WAIT-1状态

CLOSE-WAIT：表示在等待关闭

 当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态

 在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方

FIN-WAIT-2：只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文

CLOSING：一种比较罕见的例外状态

 表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文

  如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也就会出现CLOSING状态

  表示双方都正在关闭连接

LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文、

 当收到ACK报文后，即可进入CLOSED状态了

TIME-WAIT：表示收到了对方的FIN报文，并发出了ACK报文，就等2MSL后即可进入CLOSED状态了

 如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时

  可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态

CLOSED：关闭状态

由于有些状态的时间比较短暂，所以很难用netstat命令看到，比如SYN-RCVD、FIN-WAIT-1等

2.9.2 释放连接–疑问

为什么释放连接时，要进行4次挥手？

 TCP是全双工模式

 第1次挥手：当主机1发出FIN报文段时

  表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据

 第2次挥手：当主机2返回ACK报文段时

  表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的

 第3次挥手：当主机2也发送了FIN报文段时

  表示主机2告诉主机1，主机2已经没有数据要发送了

 第4次挥手：当主机1返回ACK报文段时

  表示主机1已经知道主机2没有数据发送了，随后正式断开整个TCP连接

2.9.3 释放连接–细节

TCP/IP协议栈在设计上，允许任何一方先发起断开请求，以下演示client主动要求断开

client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接

 一般是等待2倍的MSL（最大分段生存期）

  MSL是TCP报文在Internet上的最长生存时间

  每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟

如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN

 这时可能出现的情况是：

  ①client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源

  ②client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来它可能是想跟server建立连接的

2.9.4 释放连接–抓包

有时候在是用抓包工具时，有可能只会看到“3次”挥手

 这其实是将第2、3次挥手合并了

当server接收到client的FIN时，如果server后面也没有数据要发送给client了

 这时，server就可以将第2、3次挥手合并，同时告诉client两件事

  已经知道client没有数据要发

  server已经没有数据要发了

三、HTTP（超文本传输协议）

是互联网中应用最广泛的应用层协议之一

设计HTTP最初的目的是：提供一种发布和接收HTML页面的方法，由URI来标识具体的资源

后来用HTTP来传递的数据格式不仅仅是HTML，应用非常广泛

HTML：超文本标记语言

 用以编写网页

3.1 http工作原理

http消息结构：

 一个http请求报文由请求行、请求头、空行和请求数据四部分组成

3.1.1请求行

请求行由请求方法字段、url字段和http协议版本字段构成

如：

 GET/index.html HTTP/1.1

GET请求

 当点击网页上的链接或者通过浏览器的地址栏输入网页来浏览网页，使用的都是GET方式

 该方式不适合传送私密数据

POST请求

 post方法可以允许客户端给服务端提供信息较多。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，这样POST方式读传送的数据大小没有限制，也不会显示在URL中

3.1.2 请求头

3.1.3 空行

 最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头

3.1.4 请求数据

 请求数据在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最长使用的请求头Content-Type和Content-Length

3.2 http响应

由三部分组成，分别是状态行，响应头，空行，响应正文

3.2.1 状态行

状态行通过状态码来说明所请求的资源情况

1xx：指示信息–表示请求已接收，急需处理

2xx：成功–表示请求已被成功接收，理解

3xx：重定向–要完成请求必须进行更近一步的操作

4xx：客户端错误–请求有语法错误或请求无法实现

5xx：服务端错误–服务器未能实现合法的请求

常见的状态码描述：

 200 OK：客户端请求成功

 400 Bad Request：客户端请求有语法错误，不能被服务器解析

 401 Unauthorized：请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用

 403 Forbidden：服务器收到请求，但是拒绝服务

 404 Not Found：请求资源不存在，例如：输入错误的URL

 500 Internal Server Error：服务器发生不可预期的错误

 503 Server Unavaliable：服务器当前不能处理客户端的请求，一段时间后可能恢复

3.3 关于http请求GET和POST的区别–面试

 GET提交：请求的数据会附在url之后，以？分隔url和传输数据，多个参数用&连接。

 POST提交：把提交的数据放置在是http包的包体中

GET提交的数据会在地址栏中显示出来，POST提交，地址栏不会改变

2.传输数据的大小：

http协议没有对传输的数据大小进行限制

3.安全性：
 POST安全性比GET的安全性高

3.4 版本

3.5 标准

3.6 报文格式

请求报文示例：

响应报文示例：

3.6.1 报文格式–整体

3.6.2 报文格式–request-line、status-line

3.6.3 报文格式–header-filed、message-body

3.7 ABNF（是BNF的修改、增强版）

在RFC 5234中表明：ABNF用作internet中通信协议的定义语言

ABNF是最严谨的HTTP报文格式描述形式，脱离ABNF谈论HTTP报文格式，往往都是片面、不严谨的

3.7.1 ABNF–核心规则

3.8 URL的编码

URL中一旦出现了一些特殊字符（如中文，空格），需要进行编码

 在浏览器地址栏输入URL时，是采用UTF-8进行编码

3.9 Xshell + telnet

Xshell（安全终端模拟软件），在Xshell中使用telnet

telnet命令：

 可以直接面向HTTP报文与服务器交互

 可以更清晰、直观地看到请求报文、响应报文的内容

 可以检验请求报文格式的正确与否

3.10 请求方法

8种请求方法：

GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE

GET：常用于读取的操作，请求参数直接拼接在URL的后面（浏览器对URL是有长度限制的）

POST：常用于添加、修改、删除的操作，请求参数可以放到请求体中（没有大小限制）

HEAD：请求得到与GET请求相同的响应，但没有响应体

&emxp;使用场景举例：在下载一个大文件前，先获取其大小，再决定是否要下载，以此可以节约带宽资源

OPTIONS：用于获取目的资源所支持的通信选项，如，服务器支持的请求方法

&emxp;OPTIONS * HTTP/1.1

PUT：用于对已存在的资源进行整体覆盖

PATCH：用于对资源进行部分修改（资源不存在，会创建新的资源）

DELETE：用于删除指定的资源

TRACE：请求服务器回显其收到的请求信息，主要用于HTTP请求的测试或诊断

CONNECT：可以开启一个客户端与所请求资源之间的双向沟通的通道，他可以用来创建隧道（tunnel）

&emxp;可以用来访问采用了SSL（HTTPS）协议的站点

3.11 头部字段（Header Field）

头部字段可以分为4中类型：

请求头字段：

&emxp;有关要获取的资源或客户端本身信息的消息头

响应头字段：

&emxp;有关响应的补充信息，如，服务器本身（名称和版本等）的消息头

实体头字段：

&emxp;有关实体主体的更多信息，如，主体长度（Content-Length）或其MIME类型

通用头字段：

&emxp;同时适用于请求和响应信息，但与消息主体无关的消息头

3.11.1 请求头字段

q值越大，表示优先级越高
如果不指定q值，默认是1.0（1.0是最大值）

3.11.2 响应头字段

3.11.3 状态码（Status Code）

状态码用来指示HTTP请求是否成功完成

状态码可以分为5类：

 信息响应：100 ~ 199

 成功响应：200 ~ 299

 重定向：300 ~ 399

 客户端错误：400 ~ 499

 服务器错误：500 ~ 599

常见状态码：

100 Continue：

 请求的初始部分已经被服务器收到，并且没有被服务器拒绝，客户端应该继续发送剩余的请求，如果请求已经完成，就忽略这个响应

 允许客户端发送带请求体的请求前，判断服务器是否愿意接收请求（服务器通过请求头判断）

 在某些情况下，如果服务器在不看请求体就拒绝请求时，客户端就发送请求体是不恰当的或低效的

200 OK：请求成功

302 Found：请求的资源被暂时移动到了由Location头部指定的URL上

304 Not Modified：说明无需再次传输请求的内容，也就是说可以使用缓存的内容

400 Bad Request：由于语法无效，服务器无法理解该请求

401 Unauthorized：由于缺乏目标资源要求的身份验证凭证

403 Forbidden：服务器端有能力处理该请求，但是拒绝授权访问

404 Not Found：服务器端无法找到所请求的资源

405 Method Not Allowed：服务器禁止了使用当前HTTP方法的请求

406 Not Acceptable：服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应

408 Request Timeout：服务器想要将没有在使用的连接关闭

 一些服务器会在空闲连接上发送此消息，即便是在客户端没有发送任何请求的情况下

500 Internal Server Error：所请求的服务器遇到意外的情况并阻止其执行请求

501 Not Implemented：请求的方法不被服务器支持，因此无法被处理

 服务器必须支持的方法（即不会返回这个状态码的方法）。只有GET和HEAD

502 Bad Gateway：作为网关或代理角色的服务器，从上游服务器（如tomcat）中接收到的响应是无效的

503 Service Unavailable：服务器尚未处于可以接受请求的状态

 通常造成这种情况的原因是由于服务器停机维护或已超载

3.12 form提交

3.12.1 form提交–常用属性

action：请求的URI

 URL比较完整，无需URL，使用URI相对路径即可

method：请求方法（GET、POST）

enctype：POST请求时，请求体的编码方式

 application/x-www-form-urlencoded（默认值）

  用&分割参数，用=分隔键和值，字符用URL编码方式进行编码

 multipart/form-data

  文件上传时必须使用这种编码方式

3.12.2 form提交–multipart/form-data

请求头：

3.13 跨域

3.13.1 同源策略

浏览器有个同源策略（Same-Origin Policy）

 它规定了：默认情况下，AJAX请求只能发送给同源的URL

 同源是指3个相同：协议、域名（IP）、端口

img、script、link、iframe、video、audio等标签不受同源策略的约束

3.13.2 跨域资源共享

解决AJAX跨域请求的常用方法：

 CORS（Cross-Origin Resource Sharing），跨域资源共享

CORS的实现需要客户端和服务器同时支持：

 客户端

  所有的浏览器都支持（IE至少是IE10版本）

 服务器

  需要返回相应的响应头（如Access-Control-Allow-Origin）

  告知浏览器这是一个允许跨域访问的请求

3.14 Cookie、Session

Cookie：

 在客户端（浏览器）存储一些数据，存储到本地磁盘（硬盘）

 服务器可以返回Cookie交给客户端去存储

默认有效时间是30分钟

Session：

 在服务器存储一些数据，存储到内存中

request.getSession（）的执行流程：

 ①如果request没有带JSESSIONID，就会创建新的Session对象

 ②如果request带了JSESSIONID，就会返回对应的Session对象

3.15 代理服务器（Proxy Server）

特点：

 本身不生产内容

 处于中间位置转发上下游的请求和响应

  面向下游的客户端：它是服务器

  面向上游的服务器：它是客户端

3.15.1 正向代理、反向代理

正向代理：代理的对象是客户端

反向代理：代理的对象是服务器


正向代理的作用：

 隐藏客户端身份

 绕过防火墙（突破访问限制）

 Internet访问控制

 数据过滤

反向代理的作用：

 隐藏服务器身份

 安全防护

 负载均衡

3.15.2 抓包工具的原理

Fiddler、Charles等抓包工具的原理：在客户端启动了正向代理服务

注：
 Wireshark的原理是：通过底层驱动，拦截网卡上流过的数据

3.15.3 代理服务器–相关的头部字段

Via：追加经过的每一台代理服务器的主机名（或域名）
X-Forwarded-For：追加请求方的IP地址
X-Real-IP：客户端的真实IP地址

如：

①：

 X-Forwarded-For：14.14.14.14
 X-Real-IP：14.14.14.14
 Via：proxy1

②：

 X-Forwarded-For：14.14.14.14，220.11.11.11
 X-Real-IP：14.14.14.14
 Via：proxy1，proxy2

③：

 Via：proxy2

④：

 Via：proxy2，proxy1

3.16 CDN（内容分发网络）

利用最靠近每位用户的服务器，更快更可靠地将音乐、图片、视频等资源文件（一般是静态资源）传递给用户

以前：

现在：

3.16.1 使用CDN前后

CDN运营商在全国、乃至全球的各个大枢纽城市都建立了机房

部署了大量拥有高存储高带宽的节点，构建了一个跨运营商、跨地域的专用网络

内容所有者向CDN运营商支付费用，CDN将其内容支付给最终用户

3.16.2 使用CDN前

3.16.3使用CDN后

3.16.4 CDN–使用举例

使用CDN引入jQuery