HTTP

格式

非持续连接和持续连接

• 非持续连接（HTTP 1.0）：每个请求/响应报文经一个单独的TCP连接发送

  
  • 响应1个对象：2RTT+文件传输时间
  • 非持久性连接的问题
    • 每个对象需要2个RTT
    • 操作系统需要为每个TCP连接开销资源(overhead)

• 持续连接（HTTP 1.1）：所有请求/响应经相同的TCP连接发送

  • 保持TCP连接打开
    • TCP连接经过一定时间没有使用，则关闭
  • 两种方式
    • 非流水线方式
    • 流水线方式（可以并行）

细节阐述

Http 首部（大概是40多个，根据实际用途分为4中类型）

• 通用首部字段（General Header Fields） 请求和响应报文两方都会使用的首部字段。
  • 常见：date、Cache-Control、pragma（历史遗留字段，仅为 no-cache）、Transfer-Encoding（传输编码，如 chunk）
• 请求首部字段（Reauest Header Fields）客户端向服务器发送请求的报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关的优先等级信息。
  • 常见：Accept（媒体类型）、Accept*（Encoding、Language、Charset）、If*（Match、Modified-since、…）、Host（目标主机域名或IP，因为被 DNS 解析后没有域名了）、Rerfer（发起请求页面域名或IP，包含相对路径，即 “/” 后的）、Origin（发起请求的页面或IP，不包含相对path，用来判断跨域）、UserAgent、range
• 响应首部字段（Response Header Fields）从服务器向客户端响应时使用的字段，补充响应的附加内容，也会要求客户端附加额外信息
  • 常见：Accept-Range、Location（重定向的url）、Server
• 实体首部字段（Entiy Header Fields） 针对请求报文和响应报文的实体部分使用首部。补充了资源内容更新时间等实体有关的信息。
  • 常见：Content*（Language、Encoding、Lenth、Type、Ranges…）

HTTP状态码

版本对比

HTTP协议

• HTTP使用TCP而不是UDP的原因在于（打开）一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。

• HTTP协议的性能瓶颈及其优化技巧都是基于TCP协议本身的特性。

  • 如TCP建立连接时三次握手有1.5个RTT（round-trip time）的延迟，并且 TCP 还有慢启动的特性，开始时的发送窗口也很小，所以应用层会选择不同策略的连接重用方案。

• HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

Http1.x

• 缺陷：请求限制阻塞，在同一时间，同一域名的请求有一定数量限制（连接数的限制和一个连接允许发送的请求数限制），超过限制数目的请求会被阻塞。会让每个连接的流水线经常出现断流，因为尤其一个 前端页面的文件，在初始化的时候会有许多请求（包括 png、js、css 还有其他静态资源或者 ajax 请求）。
  • 还有对请求大小没有限制，如果一个请求很耗时，那么这个请求就长时间得不到回复，那么浏览器没法发下一个请求，会加剧流水线断流。

• http1.0

  • 缺陷：连接无法复用，延时和资源消耗
  • 解决方案：添加头信息——非标准的Connection字段Connection: keep-alive

• http1.1

  • 持久连接：引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用
  • 管道机制：即在同一个TCP连接里面，客户端可以同时发送多个请求。
  • 断点续传：HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始，使用 Range（请求头） & Content-Range（响应头）
  • 新增请求方式：PUT、DELETE、OPTIONS、TRACE、CONNECT
  • 其他请求头：身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

HTTP/2.0

• 特点

  • 采用二进制格式而非文本格式；
  • 完全多路复用，而非有序并阻塞的、只需一个连接即可实现并行；
  • 使用报头压缩，降低开销
  • 服务器推送

• 二进制协议

  • HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”：头信息帧和数据帧。
  • 二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。

• 完全多路复用

  • HTTP/2 的多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。
  • 因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。

• 报头压缩

  • HTTP 协议是没有状态，导致每次请求都必须附上所有信息。所以，请求的很多头字段都是重复的，比如Cookie，一样的内容每次请求都必须附带，这会浪费很多带宽，也影响速度。
  • 对于相同的头部，不必再通过请求发送，只需发送一次；
    • 客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，产生一个索引号，之后就不发送同样字段了，只需发送索引号。
  • HTTP/2 对这一点做了优化，引入了头信息压缩机制；
    • 头信息使用gzip或compress压缩后再发送；

• 服务器推送

  • HTTP/2 允许服务器未经请求，主动向客户端发送资源；
  • 通过推送那些服务器任务客户端将会需要的内容到客户端的缓存中，避免往返的延迟

SMTP、POP3

Email应用的构成组件

• 邮件客户端(user agent)
  • 读、写Email消息
  • 与服务器交互，收、发Email消息
  • Outlook, Foxmail, Thunderbird
  • Web客户端
• 邮件服务器
  • 邮箱：存储发给该用户的Email
  • 消息队列(message queue)：存储等待发送的Email
• SMTP协议(Simple Mail Transfer Protocol)
  • 邮件服务器之间传递消息所使用的协议
  • 客户端：发送消息的服务器
  • 服务器：接收消息的服务器

Email消息的传输/交换协议：SMTP 协议

• 使用TCP进行email消息的可靠传输

  • 端口25

• 传输过程的三个阶段

  • 握手
  • 消息的传输
  • 关闭

• SMTP以命令—应答的方式实现双方的通信

  • 14个命令：ASCII文本
  • 21种应答信息：状态代码和语句

• 交互示例

  • telnet servername 25
  • 服务器返回代码220
  • 输入以下命令与SMTP服务器交互：HELO、MAIL FROM、RCPT TO、DATA、 QUIT
  

Email 消息格式

• RFC 822：文本消息格式标准

  • 头部行(header)：To、From、Subject
  • 消息体(body)：消息本身（只能是ASCII字符）

• MIME：多媒体邮件扩展 RFC 2045, 2056

  • 通过在邮件头部增加额外的行以声明MIME的内容类型

    • 增加了邮件主体的结构
    • 定义了传送非ASCII的编码规则
    

  • 增加5个新的邮件首部

    • MIME-Version
    • Content-Description
    • Content-Id
    • Content-Type：邮件主体的类型
    • Content-Transfer-Encoding：邮件的编码方式，Base-64
  

SMTP一般不使用中间邮件服务器

• 发送方的邮件服务器与接收方邮件服务器直接建立TCP连接

• POP3： 采用TCP连接，端口110

  • 认证过程

    • 客户端命令
      • User：声明用户名
      • Pass: 声明密码
    • 服务器响应
      • +OK
      • -ERR

  • 事务阶段

    • List：列出消息数量
    • Retr：用编号获取消息
    • Dele: 删除消息
    • Quit