网络分层

国际标准化组织提出了 OSI 模型：应用层、表示层、会话层、运输层、网络层、链路层和物理层。

学习网络原理使用五层模型：应用层、运输层、网络层、链路层和物理层。

应用层

应用层协议定义了应用进程的通信规则，应用进程互相通信完成网络应用。

应用层协议包括：

• 域名解析系统 DNS

  DNS 是一个分布式数据库系统，存储了域名和 IP 地址的映射关系。

  主机向本地域名服务器的查询采用递归查询：如果本地域名服务器不知道被查询域名的 IP 地址，就会以 DNS 客户的身份向其他根域名服务器继续发出查询请求。

  本地域名服务器向根域名服务器查询采用迭代查询：根域名服务器会告知顶级域名服务器的地址，顶级域名服务器给出 IP 地址，或者告知下一步应该向哪个权限域名服务器进行查询。

• 文件传送协议 FTP

  FTP 通过TCP 保证可靠运输，使用两个端口，控制端口 21 和数据端口 20，分别进行控制连接和数据连接。

• 电子邮件协议

  从用户代理把邮件传送到服务器，以及在服务器之间的传送使用 SMTP 协议。

  用户代理从服务器读取邮件时使用 POP3 或 IMAP 协议。

运输层

运输层负责向主机应用进程间的通信提供数据传输服务，由于一台主机可以同时运行多个进程，因此运输层具有复用和分用的功能，复用就是多个应用进程可以同时使用运输层发送数据，分用就是把运输层收到的数据交付给对应的应用进程。

运输层协议包括：

• 用户数据报协议 UDP，提供无连接的、尽最大努力交付的数据传输服务，不保证可靠性，传输单位是用户数据报。

• 传输控制协议 TCP，提供面向连接的数据传输服务、保证可靠性，传输单位是报文。

网络层

网络层任务：① 为分组交换网上的主机提供通信服务，在发送数据时把运输层数据报封装成分组传送。② 选择合适路由，使源主机的分组通过路由器找到目的主机。

网络层协议包括：

• 网际协议 IP

  一般指 IPv4，与 IP 配套使用的还有 ARP、ICMP 和 IGMP。

  IP 数据报分为首部和数据两部分。首部前 20 字节是固定的，包含源地址、目的地址、总长度等，生存时间限制了 IP 数据报在网络中能经过的最大路由数，防止其兜圈子。

  要解决 IP 地址耗尽的问题，根本方法是采用具有更大地址空间的 IPv6（128 位）。

• 地址解析协议 ARP

  由于 IP 使用了 ARP，因此把 ARP 归到网络层，但 ARP 的作用是通过一个高速缓存，存储本地局域网的各主机和路由器的 IP 地址到硬件地址的映射表，以从网络层的 IP 解析出数据链路层的硬件地址，因此也可以把 ARP 划归在数据链路层。

  与 ARP 对应的是 RARP 逆地址解析协议，作用是通过硬件地址找到 IP 地址，被 DHCP 协议取代。

• 路由选择协议

  内部网关协议：

  • RIP：分布式的距离向量协议，适用于小型网络，按固定时间间隔与相邻路由器交换路由表信息。

  • OSPF：分布式的链路状态协议，适用于大型网络，只在链路状态变化时才向本自治系统中的所有路由器发送相邻路由器的信息。

  外部网关协议：

  • BGP-4：针对不同自治系统之间的路由器，目标是寻找一条能够到达目的网络且不兜圈子的路由。

• 网际控制报文协议 ICMP

  ICMP 报文包括差错报文和询问报文，ICMP 报文作为 IP 数据报的数据，加上首部后组成 IP 数据报发送出去。ICMP 允许主机或路由器报告差错情况，提供有关异常情况的信息。ICMP 的重要应用是分组探测 PING，测试主机间的连通性。

• 网际组管理协议 IGMP

  IGMP 的作用是让连接在本地局域网上的多播路由器知道本局域网上是否有主机的某个进程参加或退出了某个多播组。

链路层

数据链路层将网络层的分组封装成帧，在两个相邻结点间的链路上传输，每一帧包括数据和必要的控制信息（同步信息、地址信息、差错信息）。控制信息使接收端能够知道一个帧从哪个比特开始到哪个比特结束，从帧中提取出数据上交给网络层。控制信息还使接收端可以检测收到的帧有无差错，如果有差错就简单地丢弃，避免继续传送而浪费网络资源。

物理层

物理层尽可能屏蔽传输媒体和通信手段的差异，使数据链路层只需考虑本层协议和服务。

物理层的数据单位是比特，发送方和接收方发送和接收 1 或 0，因此物理层需要考虑用多大的电压代表 1 或 0，以及接收方如何识别发送方所发送的比特。此外物理层还要确定传输媒体规范，例如接线器形状、电缆电压范围等。

TCP

特点

TCP 是面向连接的，一个应用进程在向另一个进程发送数据前必须先建立连接，发送某些预备报文段。

TCP 提供全双工服务，允许通信双方的应用进程在任何时候发送数据。TCP 连接的两端都有发送缓存和接收缓存：发送时，应用程序把数据传送给 TCP 缓存后就可以做自己的事，TCP 在合适的时候发送；接收时，TCP 把收到的数据放入缓存，应用程序在合适的时候读取。

TCP 连接是点对点的，只能是单个发送方和单个接收方之间的连接。

TCP 提供可靠的交付服务，通过 TCP 传送的数据无差错、不丢失、不重复，按序到达。

TCP 是面向字节流的，流是指流入进程或从进程流出的字节序列。虽然应用程序和 TCP 的交互是每次一个数据块，但 TCP 把数据块仅看成一连串无结构的字节流。TCP 不保证接收方的数据块和发送方的数据块具有对应大小的关系，但接收方的字节流必须和发送方的字节流完全一样。应用程序必须有能力识别收到的字节流，把它还原成应用层数据。

UDP 和 TCP 的区别

UDP 无连接，发送数据前不需要建立连接，减少了开销和时延。

UDP 使用尽最大努力交付，不保证可靠性，主机不需要维持复杂的连接状态。

UDP 面向报文，UDP 对应用层报文添加首部后就交付 IP 层。

UDP 没有拥塞控制，网络拥塞不会降低源主机的发送速率，这对某些实时应用很重要，如视频会议。

UDP 支持一对一、一对多和多对多通信。

TCP 报文结构

TCP 报文段分为首部和数据两部分。首部的前 20 个字节固定，后面有 4n 字节根据需要增加。

自动重传请求 ARQ

ARQ 包括停止等待协议、回退 N 步协议和选择重传协议，后两种结合了窗口机制，属于连续 ARQ 协议。

停止等待协议

每发送完一个分组就停止发送，等待对方确认，在收到确认后再发送下一个分组。包括三种情况：

• 无差错

  A 发送分组 M~1~，发送完后暂停并等待 B 的确认；B 收到 M~1~ 后向 A 发送确认；A 收到确认后再发送下一个分组 M~2~。

• 出现差错

  B 收到 M~1~ 后检测到了差错，或者 M~1~ 在传输过程中丢失，这两种情况下 B 都不会发送确认信息，解决方法是：A 只要超过一段时间没有收到确认，就进行超时重传，每发送完一个分组就设置超时计时器，如果在计时器到期前收到确认就撤销计时。

  注意：① 发送完分组后必须暂时保留副本，收到确认再清除。② 分组和确认分组都必须进行编号。③ 超时时间应当比分组传输的往返时间稍长，过短会产生不必要的重传，过长会降低通信效率。

• 确认丢失和确认迟到

  B 发送的确认丢失，A 会超时重传，B 会丢弃重传分组并重新确认；B 发送的确认迟到，A 收到重复确认后将其丢弃。

  通常 A 最终总是可以收到对所有发出分组的确认，如果 A 不断重传分组但总收不到确认，就说明通信线路质量太差，不能通信。

停止等待协议的优点是简单，缺点是信道利用率低。为了提高传输效率，发送方可以连续发送多个分组，不必每发送完一个分组就停下来等待确认，使信道上一直有数据传送。但流水线传输可能会遇到差错，解决方法包括回退 N 步和选择重传。

TCP 可靠原理

TCP 的可靠传输包含很多机制，例如使用检验和来检测传输中的比特错误、使用定时器超时重传、使用序号检测丢失分组和冗余副本、使用确认号告诉发送方确认的分组信息。

TCP 的发送方仅需维持已发送但未确认的最小序号，以及下一个要发送的序号，从这种角度看 TCP 像一个 GBN 协议。但 TCP 和 GBN 的区别是 TCP 会将正确接收但失序的报文缓存起来，当分组 n 丢失时，GBN 会重传 n 之后的所有分组，但 TCP 至多只会重传分组 n。TCP 允许接收方有选择地确认失序报文段，而不是累积确认最后一个正确接收的有序报文段，从这个角度看 TCP 又像 SR 协议。因此 TCP 的差错恢复机制是一种 GBN 和 SR 的结合体。

滑动窗口

滑动窗口以字节为单位。发送端有一个发送窗口，窗口中的序号是允许发送的序号，窗口的后沿是已发送且确认的序号，窗口的前沿是不允许发送的序号。窗口的后沿可能不动（没有收到新的确认），也有可能前移（收到了新的确认），但不会后移（不可能撤销已经确认的数据）。窗口的前沿一般是向前的，可能不动（没有收到新的请求或对方的接收窗口变小），也可能收缩（TCP 强烈不建议这么做，因为发送端在收到通知前可能已经发送了很多数据，将产生错误）。

发送缓存存放应用程序传给 TCP 准备发送的数据和已发送但还未确认的数据；接收缓存存放按序到达但尚未被应用程序读取的数据和未按序到达的数据。

发送窗口根据接收窗口设置，但并不总是一样大，还要根据网络的拥塞情况调整。

接收方必须有累积确认功能，既可以在合适的时候确认，也可以在发送数据时捎带确认，但不能过分推迟，一般不超过 0.5 秒。

流量控制

如果应用程序读取的速度较慢，而发送方发送得太快，就会使接收缓存溢出，TCP 通过流量控制解决该问题。

TCP 通过接收窗口实现流量控制，接收窗口告诉发送方自己可用的缓存空间，发送方的发送窗口不能超过接收方的接收窗口。

当接收窗口=0 时就不再允许发送方发送数据，但可能存在一种情况：在发送零窗口报文不久后，接收方的接收缓存又有了存储空间，因此发送报文说明新的接收窗口，但该报文在传输中丢失。发送方会一直等待接收方的非零窗口通知，而接收方也一直在等待发送方发送数据，形成死锁。为解决该问题，TCP 为每个连接设有持续计时器，只要 TCP 连接的一方收到对方的零窗口通知，就启动该计时器，到期后发送一个零窗口探测报文，避免死锁。

有一种问题叫糊涂窗口综合症，当接收方处理数据很慢时，应用进程间传送的有效数据很小， 极端情况下有效数据只有 1B 但传输开销却有 40B（IP 首部及TCP 首部各占 20B) ，导致通信效率极低。为解决该问题，可以等到接收方有足够空间容纳一个最长报文段，或接收缓存已有一半空间再发送；发送方也不要发送太小的报文，而是把数据积累成足够大的报文，或达到接收方缓存一半时才发送。

拥塞控制

网络中对资源的需求超过可用量的情况就叫拥塞，当吞吐量明显小于理想吞吐量时就出现了轻度拥塞。拥塞控制就是减少注入网络的数据，减轻路由器和链路的负担，这是一个全局性问题，涉及网络中的所有路由器和主机，而流量控制是一个端到端的问题。

根据网络层是否为拥塞控制提供显式帮助，将拥塞控制分为：端到端拥塞控制和网络辅助的拥塞控制。TCP 使用端到端的拥塞控制，因为 IP 层不会向端系统提供显式的拥塞反馈。TCP 让发送方根据拥塞程度限制发送速率。如果发送方感知到没什么拥塞会增加发送速率，否则会降低发送速率。限制发送速率通过拥塞窗口实现，判断拥塞通过超时或连续接收到 3 个冗余 ACK 实现。

TCP 的拥塞控制算法包括了慢启动、拥塞避免和快恢复。慢启动和拥塞避免是 TCP 的强制部分，差异在于对收到的 ACK 做出反应时拥塞窗口增加的方式，慢启动比拥塞避免增加得更快。快恢复是推荐部分，对 TCP 发送方不是必须的。

1. 慢启动

拥塞窗口 cwnd 以一个 MSS 最大报文段开始，每当传输的报文段首次被确认就增加一个 MSS。因此每经过一个 RTT 往返时间，拥塞窗口就会翻倍，发送速率也会翻倍。

结束慢启动的情况：① 发生超时事件，发送方将 cwnd 设为 1，重新开始慢启动，并将慢启动阈值设置为 cwnd/2。② 当拥塞窗口达到慢启动阈值时就结束慢启动而进入拥塞避免模式。③ 如果检测到三个冗余的 ACK，TCP 就会执行快重传并进入快恢复状态。

2. 拥塞避免

一旦进入拥塞避免状态，cwnd 值大约是上次拥塞时的 1/2，距离拥塞并不遥远。因此 TCP 不会每经过一个 RTT 就将 cwnd 翻倍，而是较为保守地在每个 RTT 后将 cwnd 加 1。

发生超时事件时，拥塞避免和慢启动一样，将 cwnd 设为 1，并将慢启动阈值设置为 cwnd/2。

3. 快恢复

有时个别报文段丢失，但网络中并没有出现拥塞，如果使用慢启动会降低传输效率。这时应该使用快重传来让发送方尽早知道出现了个别分组的丢失，快重传要求接收端不要等待自己发送数据时再捎带确认，而是要立即发送确认。即使收到了乱序的报文段也要立即发出对已收到报文段的重复确认。当发送方连续收到三个冗余 ACK 后就知道出现了报文段丢失的情况，会立即重传并进入快恢复状态。

在快恢复中，会调整慢启动阈值为 cwnd/2，并进入拥塞避免状态。

三次握手

TCP 是全双工通信，任何一方都可以发起连接请求，假设 A 是客户端，B 是服务器。

初始 A 和 B 均处于 CLOSED 状态，B 会创建传输进程控制块 TCB 并进入 LISTEND 状态，监听端口是否收到连接请求。

当 A 要发送数据时，就向 B 发送连接请求报文，其中 SYN=1，ACK=0，SYN 不可以携带数据，但要消耗一个序号（假设 seq=x）。发送后 A 进入 SYN-SENT 同步已发送状态。

当 B 收到 A 的连接请求报文后，进入 SYN-RCVD 同步已接收状态，如果同意建立连接就会发送给 A 一个连接响应报文，其中 SYN=1，ACK=1，ack=x+1，seq=y。ack 的值为 A 发送的序号加 1，ACK 可以携带数据，如果不携带的话则不消耗序号。

当 A 收到 B 的确认后，还要对该确认再进行一次确认，报文的 ACK=1，ack=y+1，seq=x+1，发送后 A 进入 ESTABLISHED 状态，当 B 接收到该报文后也进入 ESTABLISHED 状态，客户端会稍早于服务器端建立连接。

三次握手的原因：

• 从信息对等的角度看，双方只有确定 4 类信息才能建立连接，即 A 和 B 分别确认自己和对方的发送和接收能力正常。在第二次握手后，B 还不能确定自己的发送能力和 A 的接收能力，只有在第三次握手后才能确认。

• 报文的生存时间往往会超过 TCP 请求的超时时间，A 的某个超时连接请求可能会在双方释放连接后到达 B，B 会误以为是 A 创建了新的连接请求，然后发送确认报文创建连接。由于 A 的状态不是 SYN_SENT，将直接丢弃 B 的确认数据。如果是两次握手，连接建立，服务器资源被白白浪费；如果是三次握手，B 由于长时间没有收到确认，最终超时导致连接失败，不会出现脏连接。

四次挥手

当 A 没有要发送的数据时就会向 B 发送终止连接报文，其中 FIN=1，seq=u，u 的值为之前 A 发送的最后一个序号加 1，发送后 A 进入 FIN-WAIT-1 状态。

B 收到后响应给 A 一个确认报文，ACK=1，ack=u+1，seq=v，v 的值为 B 之前发送的最后一个序号加 1。此时 A 进入 FIN-WAIT-2 状态，B 进入 CLOSE-WAIT 状态，但连接并未完全释放，B 会通知应用进程结束 A 到 B 方向的连接，此时 TCP 处于半关闭状态。

当 B 也准备释放连接时就向 A 发送连接终止报文，FIN=1，同时还要重发 ACK=1，ack=u+1，seq=w，seq 改变的原因是在半关闭状态 B 可能又发送了数据，之后 B 进入 LAST-ACK 状态。

A 收到连接终止报文后还要再进行一次确认，确认报文中 ACK=1，ack=w+1，seq=u+1，发送完后进入 TIME-WAIT 状态，等待 2MSL 后进入 CLOSED 状态。B 收到该确认后进入 CLOSED 状态，服务器端会稍早于客户端释放连接。

四次挥手的原因：TCP 是全双工通信，两个方向的连接需要单独断开。

等待 2MSL 的原因：

• 保证被动关闭方可以进入 CLOSED 状态。MSL 是最大报文段寿命，等待 2MSL 可以保证 A 发送的最后一个确认报文被 B 接收，如果该报文丢失，B 会超时重传之前的 FIN+ACK 报文，而如果 A 在发送确认报文后立即释放连接就无法收到 B 可能超时重传的报文，也不会再次发送确认报文段，B 就无法正常进入 CLOSED 状态。

• 2MSL 时间后，本连接中的所有报文就都会从网络中消失，防止已失效连接的请求数据包与正常连接的请求数据包混淆而发生异常。

除此之外，TCP 还设有一个保活计时器，用于解决客户端故障问题，服务器每收到一次数据就重新设置保活计时器，如果 2 小时内没有收到数据就间隔 75 秒发送一次探测报文，连续 10 次没有响应后关闭连接。

TIME-WAIT

在高并发短连接的 TCP 服务器上，服务器处理完请求后立刻主动关闭连接，该场景下大量 socket 处于 TIME-WAIT 状态。TIME-WAIT 状态无法真正释放句柄资源，socket 使用的本地端口在默认情况下不能再被使用，会限制有效连接数量，成为性能瓶颈。

解决：调小 tcp_fin_timeout 的值、将 tcp_tw_reuse 设为 1 开启重用，将 tcp_tw_recycle 设为 1 开启快速回收。

HTTP

概况

HTTP 超文本传输协议，由客户程序和服务器程序实现，客户程序和服务器程序通过交换 HTTP 报文进行会话。HTTP 定义了这些报文的结构以及报文交换的方式，当用户请求一个 Web 页面时，浏览器向服务器发出对该页面中所包含对象的 HTTP 请求报文，服务器接收请求并返回包含这些对象的 HTTP 响应报文。

HTTP 使用 TCP 作为运输协议，HTTP 客户首先发起一个与服务器的 TCP 连接，一旦连接建立，浏览器和服务器进程就可以通过套接字访问 TCP。客户向它的套接字接口发送请求报文，服务器从它的套接字接口接收请求报文。

HTTP 是一种无状态的协议，服务器不存储任何关于该客户的状态信息。假如某个客户在短时间内连续两次请求同一个对象，服务器并不会因为刚刚为该客户做出了响应就不再响应，而是重新进行响应。

报文格式

请求报文

请求报文包括请求行、首部行和实体。

• 请求行包括方法、URL 和 HTTP 版本。方法包括了 GET、POST、HEAD、PUT 和 DELETE 等。HEAD 类似于 GET，当服务器收到一个 HEAD 请求时，会用一个 HTTP 报文进行响应，但并不返回请求对象，通常使用 HEAD 进行调试；PUT 常用于上传对象到 Web 服务器；DELETE 用于删除 Web 服务器上的对象。

• 首部行可以携带信息，例如 Connection:close 可以告诉服务器不要使用持续连接；User-agent 可以指明浏览器类型，服务器可以为不同类型的用户代理发送对象的不同版本。

• 在首部行后有一个空行，后面跟着的是实体。使用 GET 时实体为空，而使用 POST 时才会使用实体。

响应报文

响应报文包括状态行、首部行和实体。

• 状态行包括协议版本、状态码和对应的状态信息。

• 首部行中，Date 是服务器发送响应报文的时间；Server 指明了服务器类型，类似于请求报文中的 User-agent 。

• 实体是报文的主要部分，即所请求的对象本身。

GET 和 POST 的区别

• GET 读取一个资源，可以将 GET 数据缓存在浏览器、代理或服务端。反复 GET 不应该对访问有副作用，没有副作用被称为幂等。

  POST 不是幂等的，意味着不能随意多次执行，因此不能缓存，如果尝试重新执行 POST 请求，浏览器会弹出提示框询问是否重新提交表单。

• GET 请求由 url 触发，想携带参数就只能在 url 后附加。

  POST 请求来自表单提交，表单数据被浏览器编码到 HTTP 请求报文的请求体中。主要有两种编码格式，一种是 application/..，用来传输简单数据；另一种是 multipart/form-data格式，用来传输文件，对二进制数据传输效率高。

• 从攻击的角度说，无论 GET 还是 POST 都不安全，因为 HTTP 是明文协议。

• GET 长度受限于 url，而 url 的长度由浏览器和服务器决定。

  POST 没有大小限制，起限制作用的是服务器的处理能力。

cookie

HTTP 的无状态性简化了服务器设计，提高了性能，使其可以同时处理大量 TCP 连接。但无状态也导致服务器不能识别用户，为解决该问题 HTTP 使用 cookie 客户端会话技术对用户进行追踪。

工作流程

① 当客户通过浏览器第一次访问站点时，该站点将产生一个唯一识别码，并以此作为索引，在后端数据库中产生一个表项。

② 服务器用一个包含 Set-cookie 首部的 HTTP 响应报文对浏览器进行响应，浏览器收到后将其添加到自己管理的 cookie 文件。

③ 在下次访问该站点时，请求报文的首部行会包括这个识别码，尽管浏览器不知道客户是谁，但可以确定是同一个客户。

cookie 和 session 的区别

① cookie 只能存储 ASCII 码，而 session 可以存储任何类型的数据。

② session 存储在服务器，而 cookie 存储在客户浏览器中，容易被恶意查看。。

③ session 的运行依赖 session id，而 session id 存在 cookie 中，叫做 JSESSIONID。如果浏览器禁用了 cookie ，同时 session 也会失效（可以通过其它方式实现，比如在 url 中传递 session_id）。

输入一个 url 发生的事

判断 url 是否合法，如果不合***使用默认的搜索引擎进行搜索。如果输入的是一个域名，默认会加上一个 http 前缀。

先检查浏览器的 DNS 缓存，没有则检查本地 hosts 文件的缓存，如果仍然没有会向本地 DNS 服务器发送请求，最终本地 DNS 服务器得到域名和 IP 地址的映射关系，把结果返回给用户并进行缓存。

获取 IP 地址后，通过 TCP 三次握手建立连接，发送请求报文。

服务器收到请求报文后进行响应，主进程进行监听，创建子进程处理，先判断是否是重定向，如果是重定向则返回重定向地址。如果是静态资源则直接返回，否则通过 REST URL 在代码层面处理，最后返回响应报文。

浏览器收到 HTTP 响应报文后进行解析，首先查看响应报文的状态码，根据不同的状态码做不同处理。之后解析 HTML、CSS、JS 等文件，构建 DOM 树，渲染树，重绘。最后将像素发送 GPU 进行渲染，将渲染结果返回给用户并进行缓存。

通过 TCP 的四次挥手断开连接，如果是 HTTP1.1 则会将连接保持一小段时间。

HTTPS

HTTP 存在的问题

没有加密，无法保证通信内容不被窃听。

没有报文完整性验证，无法确保通信内容在传输中不被改变。

没有身份鉴别，无法让通信双方确认对方身份。

HTTPS 原理

HTTP over SSL，在 HTTP 传输上增加了 SSL 安全套接字层，通过机密性、数据完整性、身份鉴别为 HTTP 事务提供安全保证。SSL 会对数据进行加密并把加密数据送往 TCP 套接字，在接收方，SSL 读取 TCP 套接字的数据并解密，把数据交给应用层。HTTPS 采用混合加密机制，使用非对称加密传输对称密钥保证传输安全，使用对称加密保证通信效率。

HTTPS 流程：

① 客户发送它支持的算法列表以及一个不重数。不重数就是在协议的生存期只使用一次的数，用于防止重放攻击，每个 TCP 会话使用不同的不重数，可以使加密密钥不同，重放记录无法通过完整性检查。

② 服务器从该列表中选择一种对称加密算法（例如 AES），一种公钥加密算法（例如 RSA）和一种报文鉴别码算法，然后把它的选择、证书，一个不重数返回给客户。

③ 客户通过 CA 提供的公钥验证证书，成功后提取服务器的公钥，生成一个前主密钥 PMS 并发送给服务器。

④ 客户和服务器独立地从 PMS 和不重数中计算出仅用于当前会话的主密钥 MS，然后通过 MS 生成密码和报文鉴别码密钥。此后客户和服务器间发送的所有报文均被加密和鉴别。