计算机网络第二章应用层HTTP/HTTPS 大黑书 课堂笔记完整知识点

计算机网络笔记 第二章应用层

网络应用程序体系结构：客户-服务器体系结构（client-server architrcture), 对等体系结构（P 2 P)

进程通信的过程

1. 相同端上的的进程通信通过操作系统确定
2. 不同端上的进程通信通过计算机网络交换报文（message）相互通信，发送进程生成并向网络中发送报文，接收进程接受这些报文并可能通过回送报文进行响应。
3. 进程通过套接字（socket）的软件接口向网络发送报文和从网络接收报文
   套接字是同一台主机内应用层和传输层的应用程序编程接口，
   应用程序可以控制套接字在应用层的一切但是，对于运输层的控制仅限于 1. 选择运输协议 2. 设定几个运输层的参数
4. 进程需要定义两种信息
   1. 主机的地址（主机有 IP 地址标志）
   2. 在目的主机中指定接收进程的标识符（端口号）
5. 选择运输服务

可供应用程序使用的运输服务

运输服务的评价

1. 可靠的数据传输
2. 吞吐量
3. 定时
4. 安全性

TCP 服务

TCP 服务模型包括：面向连接服务和可靠数据传输服务

1. 面向连接服务
   在数据报文开始流动前，TCP 让客户和服务器相互交换运输层的控制信息
   在握手阶段后，一个 TCP 连接就在两个进程的套接字之间建立了
2. 可靠的数据传输服务
   通信进程可以依靠 TCP，无差错的按适当顺序交付所有发送数据
3. 拥塞控制机制当接收端和发送端的网络拥塞时，会抑制发送进程。

UDP 服务

UDP 不提供不必要服务的轻量级运输协议。
UDP 是无连接的，没有握手过程
UDP 协议不保证该报文将到达接收的进程，而且到达还可能是乱序的

应用层协议简介

应用层协议（application-layer protocol)定义了在不同端系统上的应用进程如何传递报文。

1. 交换报文类型，例如请求报文和响应报文
2. 各种报文的语法如报文中各个字段及这些字段是如何描述的
3. 字段的语义
4. 如何发送报文，发送报文的规则
   RFC（Request for Comments）是互联网工程任务组（IETF）发布的一系列文档，用于描述互联网相关协议、标准、方法和过程。
   Web 应用层协议 HTTP（超文本传输协议）就作为一个 RFC 可供使用

网络应用

1. WEB
2. 文件传输
3. 电子邮件
4. 目录服务
5. 流式视频
6. P 2 P

Web 和 HTTP

HTTP 概述

Web 的应用是层协议是超文本传输协议（HTTP), 他是 Web 的核心
HTTP 由两个程序实现：一个客户程序和一个服务程序，HTTP 定义了这些报文的结构以及客户和服务器进行报文交换的方式

一些概念

Web 页面是由对象组成，一个对象只是一个文件
多数 Web 界面含有一个HTML 基本文件（Base html)
HTTP 使用 TCP 作为它支撑运输协议
客户端的套接字接口时客户进程与 TCP 连接之间的门，在服务器的套接字接口则是服务器进程与 TCP 连接之间的门。
HTTP 不保存任何关于客户的任何信息，所以我们说 HTTP 是一个无状态协议 (stateless protocol )

非持续连接和持续连接
非持续连接：即每个请求/响应对经过一个单独的 TCP 连接发送，
持续连接：是所有请求及其响应都经相同的 TCP 连接发送

非持续连接的 HTTP

往返时间（Round-Trip Time, RTT）: 一个短分组从客户到服务器然后再返回客户所花费的时间。
RTT 包括分组传播时延，分组在中间路由器和交换机的排队时延以及分组的处理时延
三次握手：客户向服务器发送一个小 TCP 报文段，服务器用一个小 TCP 报文段做出确认和响应，最后客户向服务器返回确认。
完成三次握手的前两个部分后，客户结合三次握手的第三部分（确认）向该 TCP 连接发送一个 HTTP 请求报文。

持续连接的 HTTP

非持续连接的缺点：1. 必须为每一个请求的对象建立和维护一个全新的连接，2. 每一个对象经受两倍的 RTT 交付时延
服务器在响应后保持该 TCP 连接打开，在相同的客户和服务器之间后续的请求和响应报文能够通过相同的连接进行传送。

HTTP 报文格式

1. HTTP 请求报文

请求行 (request line) 分为三部分请求方法 url 协议版本
首部行 (header line)
实体体（entity body）

GET /somedire/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

2. HTTP 响应报文

Cookie

有 4 个组件：

1. 在 HTTP 响应报文中的首部行中的一个 cookie 首部行
2. 在 HTTP 请求报文中的首部行中的一个 cookie 首部行
3. 在用户端系统保留一个 cookie 多文件，由用户的浏览器进行管理
4. 为与 Web 站点的一个后端数据库

响应报文中：Set-cookie: 1678
请求报文：Cookie: 1678 

Session

Session 是存在服务器中的。
服务器为每个用户浏览器创建会话对象，一个浏览器独占一个，在保存用户数据时可以保存在 Session 中，
Session 的 id 是以 cookie 的形式发送给客户端
cookie 是存储在 client 的，而 session 保存在 server，sessionId 需要借助 cookie 的传递才有意义。

JWT (JSON Web Token)

JWT (全称：Json Web Token)是一个开放标准 (RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为 JSON 对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

介绍：
JWT 是由三段信息构成的，分别是 Header，Payload，Signature，将这三段信息文本用点链接一起就构成了 JWT 字符串。看起来是这个样子：aaa.bbb.ccc。

Header典型的由两部分组成：token的类型（“JWT”）和算法名称（比如：HMAC SHA256或者RSA等等）。例如{‘alg’:“HS256”,‘typ’:“JWT”}，用Base64对这个JSON加密（是对称加密）就得到JWT的第一部分。

Payload载荷就是存放有效信息的地方（可以理解为皮卡的后备箱）。有效信息包含三个部分：标准中注册的声明（这里有一组预定义的声明，它们不是强制的，但是推荐。比如：iss (issuer), exp (expiration time), sub (subject), aud (audience)等），公共的声明（可以随意定义任何信息），私有的声明（是提供者和消费者所共同定义的声明，用于在同意使用它们的各方之间共享信息）。这三部分信息都不建议放敏感信息，因为是base64对称加密的，除非信息本身已经有做过一层加密处理。第二段信息格式例子如下：{“sub”:‘123456789’,“name”:‘xiaoma’,“level”:‘1’}，同样进行Base64编码就得到JWT的第二部分。

Signature签名（可以理解为驾照），对编码过的Header、编码过的Payload、一个密钥（私钥），签名算法用是Header中指定的那个，然对它们签名得到的就是JWT的三部分。类似Signature=HS256(base64(Header)+base64(Payload)，secret)。私钥可以防止篡改和验证有效性。
那这个 token 放哪里呢？ Query 参数吗？最好把 JWT 放在 HTTP 请求的 Header Authorization，格式是 Authorization: Bearer jwtStr。

JWT 的优缺点

优点
通过JWT的实现可以看出，上述的cookie和session的问题都不存在了，安全性提高，不易被攻击者利用。利用Authorization首部传输token，无跨域问题。额外信息存储在客户端，服务端占用资源不多，也不存在session共享问题。
支持跨域
无状态（指不需要在服务端保存信息）
性能（Cookie认证要比Token认证慢很多，因为Cookie使用寻找session，则token解密即可）
缺点
一次性问题(续签和废弃问题)
安全
由于jwt的payload是使用base64编码的，并没有加密，（解决，可以将payload进行加密）因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。
性能
jwt太长由于是无状态使用JWT，所有的数据都被放到JWT里，如果还要进行一些数据交换，那载荷会更大，经过编码之后导致jwt非常长，cookie的限制大小一般是4k，cookie很可能放不下，所以jwt一般放在local storage里面。并且用户在系统中的每一次http请求都会把jwt携带在Header里面，http请求的Header可能比Body还要大。而sessionId只是很短的一个字符串，因此使用jwt的http请求比使用session的开销大得多。
其他
cookie和session storage和local storage都可以在开发者工具那里看到。session storage可以设置有效时间，关闭浏览器就失效。
token 是存在 local storage 中，local storage 关闭浏览器不会失效

Web 缓存

Web cache 也叫代理服务器（proxy server）
Web 缓存器有自己的磁盘存储空间，保存最近请求过对象的副本，他是能够代表初始 Web 服务器来满足 HTTP 请求的网络实体

1. 浏览器创建一个到 Web 缓存器的一个 TCP 连接，并向 Web 缓存器中的对象发送一个 HTTP 请求
2. Web 缓存器进行检查，看看本地是否存储人该对象的副本，如果有，Web 缓存器就向客户浏览器用 HTTP 响应报文返回该对象
3. 如果 Web 缓存器中没有该对象，它就打开一个与该对象的初始服务器端 TCP 连接，然后初始的服务器先缓存器发送具有该对象的 HTTP 响应
4. 当 Web 缓存器收到该对象时，它在本地存储空间存储一份副本，并向客户端浏览器用 HTTP 响应报文发送该副本（通过想现有的客户浏览器和 Web 缓存器之间的 TCP 连接）
   部署 Web 缓存器的原因：
5. Web 缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与 Web 缓存器之间的瓶颈带宽更是如此
6. Web 缓存器能大大减少一个机构的接入链路到因特网的通信量。

条件 GET 方法

尽管高速缓冲器可以大大减少响应时间，但是引入了新的问题对象的副本可能是陈旧的。
HTTP 协议有一种机制：允许缓存器证实它的对象是最新的。
这种机制就是条件 GET（conditional GET）方法

1. 请求报文使用 GET 方法
2. 请求报文中含有一个"If-Modified-Since: "首部行

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecusiine.com
If-Modified-Since: Wed,9 Seq 2015 09:23:24

HTTP 版本更新

HTTP/1.0

HTTP 1.0 默认使用 Connection: cloose，浏览器每次请求都需要与服务器建立一个 TCP 连接，服务器处理完成后立即断开 TCP 连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。

HTTP/1.1

Http 1.1
HTTP 1.1 默认使用 Connection: keep-alive（长连接），避免了连接建立和释放的开销；通过 Content-Length 字段来判断当前请求的数据是否已经全部接受。不允许同时存在两个并行的响应。

为什么需要持久连接？
Http 协议的初始版本中，每进行一次 Http 通信就要断开一次 TCP 连接。每次请求都会造成 TCP 连接的建立和断开，增加通信量的开销。

持久连接的特点：

• 持久连接也称为 Http keep-alive，只要任意一端没有明确提出断开连接，则保存 TCP 连接状态。

• 减少了 TCP 连接的重复建立和断开所造成的额外开销，减去了服务器端的压力。

• 持久连接使得多数请求以管线化方式（pipelining）成为可能。可以同时并行发送多个请求，而不需要一个接一个的等待响应了。（请求打包一次传输过去，响应打包一次传递回来），管线化的前提是在持久连接下。

Http 1.1 缺陷

（1）高延迟，带来页面加载速度的降低。（网络延迟问题只要由于队头阻塞，导致宽带无法被充分利用）

（2）无状态特性，带来巨大的 Http 头部。

（3）明文传输，不安全。

（4）不支持服务器推送消息。

HTTP/2

SPDY 协议：2009 年谷歌公开了 SPDY 协议，主要解决 Http 1.1 效率不高的问题。

SPDY 被当做 HTTP 2.0 的基础，其主要特性（兼容老版本 HTTP 协议，同时可以使用 SSL 功能）都在 HTTP 2.0中得到继承。

HTTP 2.0：基于 SPDY，专注于性能，目标是在用户和网站直接只用一个连接。

HTTP 2.0 新特性
（1）二进制传输

Http 2.0 将请求和响应数据分割为更小的帧，并且它们采用二进制编码 (http 1.0 基于文本格式)。多个帧之间可以乱序发送，根据帧首部的流表示可以重新组装。

（2）Header 压缩

Http 2.0 开发了专门的“HPACK”算法，大大压缩了 Header 信息。

（3）多路复用

Http 2.0 中引入了多路复用技术，很好的解决了浏览器限制同一个域名下的请求数量的问题。

多路复用技术可以只通过一个 TCP 链接就可以传输所有的请求数据。

（4）服务端推送

HTTP 2.0 在一定程度上改不了传统的“请求-应答”工作模式，服务器不再完全被动地响应请求，也可以新建“流”主动向客户端发送消息。（例如，浏览器在刚请求 html 的时候就提前把可能会用到的 JS，CSS 文件发送给客户端，减少等待延迟，这被称为“服务端推送 Server Push”）

服务器也不能随便将第三方资源推送给服务器，必须经过双方确认。

HTTP 2.0 缺点
（1）TCP 以及 TCP+TLS 建立连接的延迟（握手延迟）

（2）TCP 的队头阻塞没有彻底解决（http 2.0 中，多个请求是跑在一个 TCP 管道中的，一旦丢包，TCP 就要等待重传（丢失的包等待重新传输确认），从而阻塞该 TCP 连接中的所有请求）

因为 HTTP 2.0 存在这些缺点，所以出现了 HTTP 3.0。

HTTP/3

Google 在推行 SPDY 的时候意识到了上述 http 2.0 一系列问题，于是又产生了基于 UDP 协议的“QUIC”协议，让 HTTP 跑在 QUIC 上而不是 TCP 上。从而产生了 HTTP 3.0 版本，它解决了“队头阻塞”的问题。

特点：
（1）实现了类似 TCP 的流量控制，传输可靠性的功能。

（2）实现了快速握手功能（QUIC 基于 UDP，UDP 是面向无连接的，不需要握手和挥手，比 TCP 快）

（3）集成了 TLS 加密功能

（4）多路复用，彻底解决 TCP 中队头阻塞的问题（单个“流”是有序的，可能会因为丢包而阻塞，但是其他流不会受到影响）

总结

HTTP 1.1 的缺点：安全性不足和性能不高；

HTTP 2.0 完全兼容 HTTTP 1.0，是“更安全的 HTTP，更快的 HTTPS”，头部压缩，多路复用等技术充分利用了带宽，降低了延迟。

HTTP 3.0 的底层支撑协议 QUIC 基于 UDP 实现，又含 TCP 的特点，实现了又快又可靠的协议。

SMTP

Simple mail transport protocol （简单邮件传输协议）
它限制邮件报文的体部分（不只是首部）只能采用简单的 7 比特 ASCII 表示
发送邮件的过程：假设 Alice 想给 Bob 发送一封简单的 ASCII 报文

1. Alice 调用她的邮件代理程序并提供 Bob 的邮件地址撰写报文然后知识用户代理发送该报文
2. Alice 的用户代理把报文发给她的邮件服务器，在那里报文被放在报文队列中
3. 运行在 Alice 的邮件服务器上的 SMTP 客户端发现了报文对你这个报文，他就创建一个到运行在 bob 邮件服务器上的 SMTP 服务器的 TCP 连接
4. 经过一些初始 SMTP 握手后 SMTP 客户通过该 TCP 连接发送 Alice 的报文
5. 在 Bob 的邮件服务器上，SMTP 的服务器接受该报文然后将报文放入 Bob 的邮箱中
6. 方便时 Bob 调用用户代理阅读该报文
   SMTP 特点：
7. SMTP 一般不使用中间服务器发送邮件

与 HTTP 的对比

两个协议都用于从一台主机向另一台主机传送文件
区别：

1. HTTP 主要是一个拉协议 (puil protocol)，SMTP 基本上是一个推协议（push protocol ）
2. SMTP 要求每个报文用 7 比特 ASCII 码格式，HTTP 没有这种限制
3. 如何处理一个即包含文本又包含图形的文档
   1. HTTP 把每个对象封装到它自己的 HTTP 响应报文中
   2. SMTP 则把所有报文对象放在一个报文之中

POP 3

当用户代理（客户）打开了一个邮件服务器端口 110 上的 TCP 连接后 POP 3 就开始工作了。
工作阶段：

1. 特许（authorization）（鉴别用户身份）
2. 事务处理阶段（取回报文）
3. 更新阶段（删除有删除标记的报文）

IMAP

邮件访问协议
与 POP 3 不同的是为用户提供了创建文件夹，以及将邮件从一个文件夹移动到另一个文件夹的命令
IMAP 服务维护了 IMAP 会话的用户状态信息，例如文件夹的名字以及哪些报文和哪些报文是关联的。
IMAP 允许用户代理获取报文某些部分的命令。

DNS

因特网的目录服务
Domain Name System (域名系统)基于 udp 协议，使用 52 号端口
主要任务就是：能进行主机名到 IP 地址的转换的目录服务
DNS 是：

1. 一个由分层的 DNS 服务器实现的分布式数据库
2. 一个使主机能够查询分布式数据库的应用层协议
   提供服务：
3. 主机名到 IP 地址转换
4. 主机别名
5. 邮件服务器别名
6. 负载分配

P 2 P

P 2 P 文件分发协议：BitTorrent
自拓展性的成因：对等方除了是比特的消费者，还是他们的重新分发者

BitTorrent

BitTorrent 是一种文件分发的流行 P 2P 协议
参与一个特定文件分发的所有对等方的集合被称为一个洪流（torrent）
在一个洪流中的对等方彼此下载等长度的文件块（chunk），典型的块长度是 256 KB。
当一个对等方首次加入一个洪流中，它没有块，随着时间流逝，它积累了越来越多的块，当他下载块时同时也为其他对等方上载了多个块，一旦对等方获得了整个文件，他也许离开洪流，或者留在洪流中国年继续向其他对等方上载块。同时任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流中。
当一个新的对等方 Alice 加入洪流时
步骤：

1. 追踪器会发送给 Alice 50 个对等方的 IP 地址，与这个表上的所有对等方创建并行的 TCP 连接，所有成功创建 TCP 连接的对等方称为：“邻近对等方”
2. 在任何给定时刻，Alice 将具有块的子集，并知道它的邻居具有哪些块，这是她需要做出两个决定：1. 她应当从她的邻居请求哪些块呢？2. 应当向哪些向她请求块的邻居发送块。解决第一个问题是：最稀缺优先（rarest first），解决第二个问题是疏通

视频流和内容分发网（CDN）