HTTP协议

一、HTTP报文

1.1报文流动

HTTP 使用术语流入(inbound) 和流出(outbound) 来描述事务处理 (transaction)的方向。 报文流入源端服务器， 工作完成之后， 会流回用户 的 Agent 代理中

1.2 报文的组成部分

HTTP 报文是简单的格式化数据块。 每条报文都包含一条来自客户端的请求，或者一条来自服务器的响应。 它们由三个部分组成:

• 对报文进行描述的起始行(start line)
• 包含属性的首部(header)块
• 以及可选的包含数据的主体(body) 部分

所有的 HTTP 报文都可以分为两类: 请求报文(request message) 和 响应报文(response message)请求报文会向 Web 服务器请求一个动作。 响应报文会将请求的结果返回给客户端。 请求和响应报文的基本报文结构相 同。

报文格式

• 请求报文

  

• 响应报文

  

二、三次握手

• 准备工作

  最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

  TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN(监听)状态

• 一次握手:

  TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文， 这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x

  此时，TCP客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP规 定，SYN报文段(SYN=1的报文段)不能携带数据，但需要消耗掉一个序号

• 二次握手

  TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应 该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD(同步收到)状态。这个报文 也不能携带数据，但是同样要消耗一个序号

  ACK为1表示确认号有效，为0表示报文中不包含确认信息

• 三次握手

  TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1， ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入 ESTABLISHED(已建立连接)状态。TCP规定，ACK报文段可以携带数据，但 是如果不携带数据则不消耗序号。

为什么TCP客户端最后还要发送一次确认呢?

• 主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误

为什么要3次握手?

客户端和服务端通信前要进行连接，3****次握手的作用就是双方都能明确自己和 对方的收、发能力是正常的

• 第一次握手

  客户端发送网络包，服务端收到了。这样服务端就能得出结
  论:客户端的发送能力、服务端的接收能力是正常的

• 第二次握手

  服务端发包，客户端收到了。这样客户端就能得出结论:服务
  端的接收、发送能力，客户端的接收、发送能力是正常的

• 第三次握手

  第三次握手:客户端发包，服务端收到了。这样服务端就能得出结论:客户 端的接收、发送能力，服务端的发送、接收能力是正常的。 第一、二次握手 后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第 三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度， 我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送 能力是正常的。而客户端的接收能力也是正常的

三、TCP协议缺陷

DDOS又称为分布式拒绝服务，全称是Distributed Denial of Service。DDOS本 是利用合理的请求造成服务器资源过载，导致服务不可用。常见的DDOS攻击有 SYN flood(SYN flood)、UDP flood、ICMP、flood等，其中SYN flood是一 种最为经典的DDOS攻击。SYN flood如此猖獗是因为它利用了TCP协议设计中 的缺陷，而TCP/IP协议是整个互联网的基础，牵一发而动全身，如今想要修复 这样的缺陷几乎成为不可能的事情

SYN flood攻击原理:

• SYN flood在攻击时，首先伪造大量的源IP地址，分别向服务器端发送大量 的SYN包
• 服务器端返回SYN/ACK包，因为源地址是伪造的，所以伪造的IP并不会应 答
• 服务器端没有收到伪造IP的回应，会重试3~5次并且等待一个SYN Time(— 般为30秒至2分钟)，如果超时则丢弃这个连接
• 攻击者大量发送这种伪造源地址的SYN请求，服务器端将会消耗非常多的资 源来处理这种半连接，同时还要不断地对这些IP进行SYN+ACK重试
• 最后的结果是服务器无暇理睬正常的连接请求，导致拒绝服务。

四、四次挥手

• TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。
• 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和 SYN一样，一个FIN将占用一个序号。
• 服务器关闭客户端的连接，发送一个FIN给客户端。
• 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

为什么客户端最后还要等待2MSL

• 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报 文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开 了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是 服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的 报文，接着给出回应报文，并且会重启2MSL计时器
• 等待2MSL时间，客户端就可以放心地释放TCP占用的资源、端口号。 如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络 里的老的TCP报文可能与新TCP连接报文冲突，造成数据冲突，为避免此种情 况，需要耐心等待网络老的TCP连接的活跃报文全部死翘翘，2MSL时间可以满 足这个需求(尽管非常保守)