TCP

传输控制协议（英语：Transmission Control Protocol，缩写：TCP）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC 793 定义。在简化的计算机网络 OSI 模型中，它完成第四层传输层所指定的功能。 毫不夸张地说，TCP 协议是目前整个互联网的基础。它解决了一系列的网络问题。带来的结果，就是协议本身非常复杂。考虑到文章篇幅问题，本文着重说明 TCP 建立连接时的三次握手过程和关闭连接时的四次挥手过程。 三次握手 图 1. TCP 三次握手 第一次握手(SYN=1, seq=x): 客户端发送一个 TCP 的 SYN 标志位置 1 的包，指明客户端打算连接的服务器的端口，以及初始序号 x，保存在包头的序列号(Sequence Number)字段里。 发送完毕后，客户端进入 SYN_SEND 状态。 第二次握手(SYN=1、seq=y；ACK=1、ACKnum=x+1): 服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为 1。服务器端选择自己 ISN 序列号，放到包头的序列号(Sequence Number)字段里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加 1，即 x+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。 第三次握手(ACK=1，ACKnum=y+1) 客户端再次发送确认包(ACK)，SYN 标志位为 0，ACK 标志位为 1，并且把服务器发来 ISN 的序号字段+1，放在确定字段中发送给对方，即数据段放写 y+1。 发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。 SYN Flood 攻击 在三次握手过程中，服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后，服务器才能转入 ESTABLISHED 状态.

HTTP1.0 根据谷歌的调查， 现在请求一个网页，平均涉及到 80 个资源，30 多个域名。考虑最原始的情况，每请求一个资源都需要建立一次 TCP 请求，显然不可接受。HTTP 协议规定了一个字段 Connection，不过默认的值是 close，也就是不开启。 HTTP1.1 Pipeline 是为了减少不必要的 TCP 连接，但依然存在队头阻塞(HOC)的缺点，一种解决思路是利用并发连接减少某一个 HOC 的影响，另一个是共享(注意与复用的区别) TCP 连接，直接避免 HOC 问题的发生。 HTTP1.1 的缺陷 高延迟 — 队头阻塞(Head-Of-Line Blocking) 当有多个串行请求执行时，如果第一个请求不执行完，后续的请求也无法执行。 支持并发请求是解决解决 HOC 问题的一种方案，并发请求并非是直接解决了 HOC 的问题，而是尽可能减少 HOC 造成的影响。 将同一页面的资源分散到不同域名下，提升连接上限。 减少请求数量 内联一些资源：css、base64 图片等 合并小文件减少资源数 无状态特性 — 阻碍交互 明文传输 — 不安全性 HTTP 1.x 也可以配合 TLS 进行安全传输，只是不是强制的。 不支持服务端推送 SPDY SPDY 是由 Google 推行的改进版本的 HTTP1.1。 针对 HTTP1.1 的缺陷，SPDY 提供了如下特性： 多路复用 — 解决队头阻塞 SPDY 允许在一个连接上无限制并发流。因为请求在一个通道上，TCP 效率更高。