计算机网络总结

动态主机配置协议（Dynamic Host Configuration Protocal）简称DHCP，常用于给主机动态地分配IP地址
DHCP提供了即插即用联网的机制，这种机制允许一台计算机加入新的网络和获取IP地址而不用手工参与
DHCP是应用层协议，基于UDP

DHCP采用C/S方式（只有应用层有这种工作方式）

• 需要IP地址的主机在启动时就广播发现报文，这时该主机就称为DHCP客户
• 局域网上所有主机都能收到发现报文，但只有DHCP服务器才回答此发现报文
• DHCP在收到发现报文后，先在其数据库中查找该计算机的配置信息，若找到，则返回找到的信息，若找不到，则从服务器的IP地址池中取一个地址分配给该计算机
  当看到发出方IP是0.0.0.0，接收方是255.255.255.255，于是DHCP服务器知道“这个包是发过我的”，而其他计算机就可以丢弃这个包
  

域名系统（Domain Name System, DNS）是因特网使用的命名系统，用来把人们方便记忆的具有特定含义的主机名（如www.baidu.com）转换为便于机器处理的IP地址
任何一个连接到因特网上的主机，都有一个唯一的层次结构名称，即域名
一般一个域名由三个子域组成，分别是顶级域、二级域、三级域，级别最低的域名写在最左边，级别最高的顶级域名写在最右边
域名系统中，每个域分别由不同的组织进行管理，每个组织都可以将它的域再分成一定数目的子域，并将这些子域委托给其他组织去管理

DNS采用C/S模型，基于UDP协议，端口号为53

统一资源定位符
负责标识WWW（万维网）上的各种资源，并使每个资源在整个WWW的范围内具有唯一的URL
 URL是对可以从因特网上得到的资源的位置和访问方法的一种简洁表示
URL相当于一个文件名在网络范围的扩展
URL的一般形式是：<协议>://<主机>:<端口>/<路径>

• 常见的协议有http、ftp等
• 主机是存放资源的主机在因特网中的域名，也可以是IP地址
• 端口和路径有时可以省略
• URL中不区分大小写

HTTP协议
HTTP定义了浏览器怎样向服务器请求资源，以及服务器怎样把资源传送给浏览器
HTTP规定了在浏览器和服务器之间的请求和响应的格式与规则，是WWW上能够可靠地交换文件的重要基础
HTTP有多个版本，目前广泛使用的是HTTP/1.1版本
HTTP是一个应用层协议，使用TCP连接进行可靠的传输

HTTP协议的特点
简单快速
灵活
无状态

• 无状态是指服务端没有存储客户端的状态、对于事务处理没有记忆，后续处理需要前面的信息，则必须重传
• 为了弥补无状态的不足，产生了两项记录HTTP状态的技术，分别是Cookie和Session
  

无连接

• 无连接指的是限制每次连接只处理一个请求，服务器处理完客户端的请求并收到客户端的应答后即断开连接，无连接是为了尽快将资源释放出来给其他客户端
• 无连接对于服务器来说处比较简单，因为存在的连接都是有用的连接，不需要额外的控制，但如果客户端连接频繁，会在tcp连接的频繁建立和关闭上浪费资源
• HTTP/1.1提出持久连接（HTTP Keep-Alive），在持久连接中只要任意一端没有明确提出断开连接，则保持TCP连接状态，在请求首部字段中的Connection: keep-alive表明使用了持久连接

Cookie和Session结合进行HTTP状态存储

• Cookie是客户端的解决方案，由服务器发给客户端的特殊信息会以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息
• Session是服务器端使用的一种记录客户端状态或信息的机制
• 通过Cookie存储一个session_id，然后具体的数据则保存在Session中
• 如果用户已经登录，则客户端会在Cookie中保存一个session_id，下次再次请求的时候会把该session_id携带上来，服务器根据session_id在Session库中获取用户的session数据，就能知道该用户到底是谁，以及之前保存的一些状态信息；

访问一个URL时所发送的事情
以访问http://www.tsinghua.edu.cn/chn/index.htm为例
  a. 浏览器分析URL
  b. 浏览器向DNS域名服务器请求解析www.tsinghua.edu.cn的IP地址
  c. 域名系统DNS解析出清华大学服务器的IP地址
  d. 浏览器与清华大学服务器建立TCP链接
  e. 浏览器发出HTTP请求：GET /chn/index.htm
  f. 服务器通过HTTP响应把文件index.htm发送给浏览器
  g. TCP链接释放
  h. 浏览器解释index.htm文件，并将Web页面显示给用户

HTTP报文概述
  ○ HTTP报文是面向文本的，报文中的每一个字段都是一些ASCII码串，各个字段的长度是不确定的。
  ○ HTTP有两类报文，请求报文（从Web客户端向Web服务器发送服务请求）和响应报文（从Web服务器对Web客户端请求的回答）

HTTP请求报文
一个HTTP请求报文由请求行、请求头部、空行和请求体4个部分组成
1. 请求行（Request Line）
请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔，例如GET /index.html HTTP/1.1
常见的请求方法有GET、POST、HEAD
a. GET

• GET是最常见的一种请求方式，当客户端要从服务器中读取文档、点击网页上的链接、通过在浏览器的地址栏输入网址来浏览网页时，使用的都是GET方式
• GET方式要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面（因此参数在请求行中），利用?代表URL的结尾与请求参数的开始，利用&分隔多个参数。
• 利用GET方式传参时，参数的值可以直接在URL中看到。显然，GET方式不适合传送私密数据
• 另外，不同的浏览器对URL的字符限制也有所不同，一般最多只能识别1024个字符，所以如果需要传送大量数据的时候，也不适合使用GET方式

b. POST

• 对于上面提到的不适合使用GET方式的情况，可以考虑使用POST方式
• POST方法将请求参数封装在HTTP请求体中，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中
• GET多用来查询，请求参数放在URL中，不会对服务器上的内容产生作用；POST多用来提交，如把表单内容放到Request Body中

c. HEAD
  ○ HEAD类似于GET，不同的是服务端接受到HEAD请求后只返回响应头，而不会发送响应内容
  ○ 当我们只需要查看某个页面的状态的时候，使用HEAD非常高效，因为在传输的过程中省去了页面内容

2. 请求头（Request Header）
请求头由关键字/值对组成，每行一对，关键字和值用英文冒号:分隔
请求头部通知服务器关于客户端请求的信息，典型的请求头有

• User-Agent：产生请求的浏览器类型
• Host：请求的服务器套接字（1.1以后才有）
• Content-Length：Request Body中数据的长度
• Content-Type：指定Request Body中数据的编码类型（如application/json），服务器根据该类型使用特定的解析方式解析请求体
• Connection：指定是否是HTTP持久连接（即Keep-Alive）

3. 请求体（Request Body）

• 请求体不在GET方法中使用，而是在POST方法中使用，POST方法会将客户端要传送的数据封装在请求体中
• 与请求体相关的最常使用的请求头是Content-Type（如json）和Content-Length

HTTP响应报文
响应报文也由三个部分组成，分别是：状态行、响应头、响应体
响应报文的格式与各部分功能与请求报文基本一致，真正的区别在于第一行中用状态行代替了请求行

状态行（Status Line）
状态行通过提供一个状态码和状态码描述来说明所请求的资源情况

状态码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值

• 1xx：指示信息--表示请求已接收，继续处理
• 2xx：成功--表示请求已被成功接收、理解、接受
• 3xx：重定向--要完成请求必须进行更进一步的操作
• 4xx：客户端错误--请求有语法错误或请求无法实现
• 5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码及状态码描述

• 200 OK：客户端请求成功。
• 400 Bad Request：客户端请求有语法错误，不能被服务器所理解。
• 401 Unauthorized：请求未经授权
• 403 Forbidden：服务器收到请求，但是拒绝提供服务。
• 404 Not Found：请求资源不存在，举个例子：输入了错误的URL。
• 500 Internal Server Error：服务器发生不可预期的错误。
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常

HTTP协议的问题

• 请求信息明文传输，容易被窃听截取
• 数据的完整性未校验，容易被篡改
• 没有验证对方身份，存在冒充危险|

HTTPS（HyperText Transfer Protocol over Secure Socket Layer）协议
为了解决上述HTTP存在的问题，就出现了HTTPS协议，HTTPS在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性
HTTPS协议一般理解为HTTP+SSL/TLS，SSL是HTTPS安全的基础，所有加密的操作都由SSL完成，可以将SSL理解为HTTP与TCP之间的加密/身份验证层

SSL（Secure Socket Layer）协议
SSL协议通过数字证书、非对称密钥技术和对称密钥技术来完成加密传输与身份认证
对称加密算法加密数据 + 非对称加密算法交换密钥 + 数字证书验证身份 = 安全

SSL加密过程（HTTPS工作过程）

1. 客户端向服务端发起请求
2. 服务端将其SSL证书发送给客户端，证书中包含服务器的公钥，而服务器自己持有该公钥对应的私钥（可以把公钥和私钥想象成一把钥匙和一个锁头，世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。）
3. 客户端对服务器的证书进行验证，并取出服务器的公钥；然后，客户端再产生一个称作pre_master_secret的随机密码串（实际上是对称加密的密钥），并使用服务器的公用密钥对其进行加密（参考非对称加 / 解密），并将加密后的信息发送给服务器；
   服务器收到后，用私钥进行解密，得到客户端传来的随机值，也就是对称加密的密钥，然后通过该密钥对将要传送的数据进行对称加密，然后发送给客户端
4. 客户端根据自己的对称加密密钥解密信息

HTTPS的缺点

• 相同网络环境下，HTTPS协议会使页面的加载时间延长近50%。此外，HTTPS 协议还会影响缓存，增加数据开销和功耗。
• HTTPS协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用。
• 最关键的是，SSL证书的信用链体系并不安全。
• 服务器成本增加。因为HTTPS协议的工作要增加额外的计算资源消耗，在大规模用户访问应用的场景下，服务器需要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本。随着云计算技术的发展，数据中心部署的服务器使用成本在规模增加后逐步下降，相对于用户访问的安全提升，其投入成本已经下降到可接受程度。

IP分组

• 一个IP分组由首部和数据两部分组成
• 首部前一部分的长度固定，共20B，是所有IP分组必须具有的

IP分片

IP地址

• 32bit，IP地址={<网络号>, <主机号>}
• 网络号0是不可指派的，表示本网络
• 网络号127用于环回测试，目的网络号为127的IP分组永远不会出现在任何网络上     
• 主机号全为0表示本网络
• 主机号全为1表示本网络的广播地址
• 0.0.0.0表示本网络上的本主机，即当前主机

子网划分

• 从主机号借用若干bit作为子网号，三级IP地址={<网络号>, <子网号>, <主机号>}

CIDR

• 无分类域间路由选择（Classless Inter-Domain Routing）简称CIDR，是在子网掩码的基础上提出的一种消除传统分类IP地址的方法
  CIDR使用“网络前缀”来代替子网络的概念，IP地址的结构变为无分类两级编址：IP地址={<网络前缀>, <主机号>}

IPv6
解决IPv4地址耗尽问题的措施有以下三种

• 采用无类别编址CIDR
• 采用网络地址转换NAT
• 采用具有更大地址空间的IPv6

前两种方法只是延长了IPv4地址分配结束的时间，只有IPv6从根本上解决了IPv4地址的耗尽问题

IPv6的主要特点

• 更大的地址空间：IPv6将地址从IPv4的32位增大到了128位（4倍）
• 允许协议继续扩充
• 自动配置地址，支持即插即用
• IPv6只在包的源节点才能分片，传输中的路由器不能分片，所以也可以说IPv6不允许分片

网络地址转换（Network Address Translation）简称NAT，是指通过将私有网络地址转换为公用地址，从而对外隐藏内部管理的IP地址
NAT使得整个私有网只需要一个公用IP地址就可以与因特网连通
NAT大大节省了IP地址的消耗，同时，NAT还隐藏了内部网络结构

私有IP地址网络号如下

• A类：1个A类网段 10.0.0.0 ~ 10.255.255.255
• B类：16个B类网段 172.16.0.0 ~ 172.31.255.255
• C类：256个C类网段 192.168.0.0 ~ 192.168.255.255

NAT路由器

• 使用私有地址的主机和外界通信时，NAT路由器使用NAT转换表将私有地址转换成公用地址，或将公用地址转换成私有地址

IP分组通过多次路由表转发到达目标网络后，改为在目标局域网中通过数据链路层的MAC地址（48bit）以广播方式寻址
地址解析协议（Address Resolution Protocal）简称ARP协议
在实际网络的链路上传送数据帧时，最终必须使用硬件地址，所以需要ARP协议来完成IP地址到MAC地址的映射
每台主机都设有一个ARP高速缓存，用来存放本局域网上各主机和路由器的IP地址到MAC地址的映射表，称ARP表，使用ARP协议来动态维护此ARP表

ARP工作原理
主机A欲向本局域网上的某台主机B发送IP分组时，先在其ARP高速缓存中查看有无主机B的IP地址

• 如果有，就可查出其对应的MAC地址，再将此MAC地址写入MAC帧，然后通过局域网将该MAC帧发往此硬件地址
• 如果没有，那么就通过使用目的MAC地址为FF-FF-FF-FF-FF-FF的帧来封装并广播ARP请求分组，使同一个局域网里的所有主机收到ARP请求
• 主机B收到该ARP请求后，向主机A发出响应ARP分组，分组中包含主机B的IP与MAC地址的映射关系，主机A在收到后将此映射写入ARP缓存，然后按查询到的MAC地址发送MAC帧。
• 尽管ARP请求分组时广播发送的，但ARP响应分组是普通的单播

如果所要找的主机和源主机不在同一个局域网上，就需要发送IP分组至本局域网上的某个路由器

• 通过ARP找到一个位于本局域网上的某个路由器的MAC地址
• 将IP分组发送给这个路由器，让这个路由器把分组转发给下一个网络

网际控制报文协议（Internet Control Message Protocol）简称ICMP
IP缺乏差错控制机制，ICMP作为IP协议差错控制的补充，使用ICMP来让主机或路由器报告差错和异常情况
ICMP是网络层协议，ICMP报文作为IP分组的数据，加上IP的首部，组成IP分组发送出去
ICMP报文有两个种类：ICMP差错报告报文和ICMP询问报文

ICMP差错报告报文共有5种类型
  a. 终点不可达
当路由器或主机不能交付IP分组时，向源主机发送终点不可达报文
  b. 源点抑制
当路由器或主机由于拥塞而丢弃IP分组时，向源主机发送源点抑制报文，使源点知道应当减慢IP分组的发送速率
  c. 时间超过
当路由器收到生存时间（TTL）为0的IP分组时，除丢弃该分组外，还要向源主机发送时间超过报文
当终点主机在预先规定的时间内不能收到一个IP分组的全部片时，就把已收到的片全部丢弃，并向源主机发送时间超过报文
  d. 参数问题
当路由器或主机收到的IP分组的首部中，有的字段的值不正确时，就丢弃该分组，并向源主机发送参数问题报文
  e. 重定向

ICMP询问报文有4种类型
  a. 回送请求和回答报文
常使用回送请求和回答报文进行分组网间探测PING（测试两台主机之间的连通性）
  b. 时间戳请求和回答报文
  c. 掩码地址请求和回答报文
  d. 路由器询问和通告报文

为了能够支持像视频点播和视频会议这样的应用场景，网络必须实施某种有效的组播机制。使用多个单播传送来仿真组播是可能的，但是这会引起主机上大量的处理开销和网络上的负担。
组播机制是让源计算机一次发送的单个分组可以抵达用一个组IP地址标识的若干目标主机

IP组播地址

• IP组播使用D类地址，D类地址的范围是224.0.0.0~239.255.255.255
• 组播地址只能用于目的地址，不能用于源地址
• 对组播数据报不产生ICMP差错报文

组播路由器必须和因特网上的其他组播路由器协同工作，以便把组播数据以最小的代价传送给所有组成员，此时就需要IGMP协议
IGMP的工作可以分为两个阶段
第一阶段

• 当某台主机想加入新的组播组时，该主机向组播组的组播地址发送一个IGMP报文，声明自己要称为该组的成员
• 本地的组播路由器收到IGMP报文后，将组成员关系转发给因特网上的其他组播路由器

第二阶段

• 本地组播路由器要周期性地探寻本地局域网上的主机，以便知道这些主机是否仍继续是组的成员

端口能够让应用层的各种应用进程将其数据通过端口向下交付给传输层，以及让传输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程
端口在传输层的作用类似于IP地址在网络层的作用或MAC地址在数据链路层的作用，IP地址和MAC地址标识的是主机，端口标识的是主机中的应用进程
套接字

• 套接字 =（主机IP地址，端口号）
• 在网络中采用套接字（Socket）来唯一地标识网络中的一台主机和其上的一个进程

UDP协议仅在IP协议之上增加了两个最基本的服务：复用和分用、差错检测（校验UDP数据报和IP地址  ）
UDP不保证可靠交付，因此维护传输可靠性的工作需要在应用层完成

UDP的优点

• UDP无须建立连接，不会引入建立连接的时延
• UDP分组的首部开销小。UDP首部为8B，而TCP首部为20B
• UDP没有拥塞控制，因此网络中的拥塞不会影响主机的发送效率
  某些实时应用要求以稳定的速度发送，能容忍一些数据的丢失，但不允许有较大的时延，UDP就可以满足这些应用的需求

UDP协议的应用

• UDP常用于一次性传输较少数据的网络应用，如DNS、DHCP等，对于这些应用，若采用TCP，则将为连接创建、维护和拆除带来不小的开销
• UDP也常用于多媒体应用，如IP电视、实时视频会议、流媒体等
• 可靠的数据传输对很多应用来说并不是最重要的，但TCP的拥塞控制会导致数据出现较大的延迟，这是很多应用不能容忍的

TCP是面向连接的传输层协议，每条TCP连接只能是一对一的
TCP提供可靠的交付服务，保证传送的数据无差错、不丢失、不重复、有序
TCP提供全双工通信，允许通信双方在任何时候都能发送数据
TCP是面向字节流的，即TCP把应用层交下来的数据视为一连串的无结构的字节流

TCP的发送缓存和接收缓存
TCP为了支持全双工通信，在发送端和接收端都设有缓存，用来临时存放双向通信的数据
发送缓存用来存放以下数据

• 发送应用程序准备发送的数据
• TCP已发送但尚未收到确认的数据

接收缓存用来存放以下数据

• 按序到达但尚未被接收应用程序读取的数据
• 不按序到达的数据

TCP可靠传输
TCP使用了以下机制来实现可靠传输
1. 序号
TCP首部的序号字段用来保证数据能有序提交给应用层，TCP传送的数据流中的每个字节都编上了序号
2. 确认
TCP首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号
3. 重传
有两种时间会出发重传：超时（当发送的报文段在一定时间内没收到确认就重传）和冗余ACK
冗余ACK指的是接收方每次收到比期望序号大的报文段时就发送一个冗余ACK，接收方在收到同一个报文的3个冗余ACK后，就可以认为被确认报文段之后的报文段已经丢失，需要重传

TCP流量控制
流量控制是指消除发送方使接收方缓存区溢出的可能性
流量控制通过接收方发送的TCP报文段的首部中的窗口字段来实现，该窗口值可以限制发送方发送窗口的大小

TCP拥塞控制
拥塞控制是指防止过多的数据注入网络，使得网络中的路由器或链路不至于过载
拥塞控制相比于流量控制来说是一个全局性的过程，涉及所有的主机和路由器
TCP发送端通过慢开始算法和拥塞避免算法来实现拥塞控制

• 慢开始算法：起始拥塞窗口为1MSS（单个最大报文长度），每经过一个传输轮次，拥塞窗口的大小*2，直到达到阈值，然后采用拥塞避免算法
• 拥塞避免算法：每经过一个传输轮次，拥塞窗口的大小增1MSS而不是加倍
• 拥塞处理：无论是在慢开始阶段还是拥塞避免阶段，只要发送方检测到超时事件发生，就把慢开始门限设置为当前拥塞窗口的一半，然后将拥塞窗口重新设置为1MSS

发送端的发送窗口 = min(拥塞窗口, 接收窗口)

TCP连接的建立 - 三次握手
1. 最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器
2. 服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
3. 第一次握手（客户端→服务器）
  ○ 客户端进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文。连接请求报文首部中的SYN=1，同时确定一个初始序列号seq=x
  ○ 此时，客户端进程进入了SYN-SENT（同步已发送状态）状态
  ○ TCP协议规定，SYN报文段（SYN=1的报文段）不能携带数据（因为连接还没建立），但需要消耗掉一个序号
4. 第二次握手（服务器→客户端）
  ○ 服务器收到请求报文后，如果同意连接，则发出确认报文
     确认报文的首部中ACK=1、SYN=1，确认号ack=x+1，同时也要确定一个初始序列号seq=y
  ○ 此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态，在该状态时服务器还会为该TCP连接分配需要的资源
5. 第三次握手（客户端→服务器）
  ○ TCP客户进程收到确认后，还要向服务器给出确认，发出确认报文。
     确认报文的ACK=1、ack=y+1，序列号seq=x+1
  ○ 此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态，在该状态时客户端还会为该TCP连接分配需要的资源
  ○ TCP协议规定，ACK报文段（ACK=1的报文段）可以携带数据，但是如果不携带数据则不消耗序号

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

• 第三次握手主要防止已经失效的连接请求报文（第一次握手）突然又传送到了服务器，从而产生错误。
• 如果使用的是两次握手建立连接，假设有这样一种场景：客户端发送了第一个请求连接报文，该报文并没有丢失，只是滞留在网络结点中。一段时间后，由于客户端没有收到确认报文，以为服务器没有收到第一个请求连接报文，所以将向服务器发送第二个请求连接报文。第二个请求连接报文正常到达服务器，经过两次握手，服务器与客户端建立连接，传输数据，然后关闭连接。然后此前滞留的第一个请求连接报文在网络通畅后到达了服务器，服务器发出确认报文，虽然这个请求连接报文本该是失效的，但是两次握手的机制将会让服务器认为TCP连接已经建立，并一直等待客户端传输数据，而此时客户端并无连接需求，因此不予理睬，这就造成了服务器的资源浪费
• 上述场景中，如果采用的是三次握手建立连接，就算第一个请求连接报文传送到服务器，服务端回复了确认报文，但是客户端不会再次发出确认。服务器收不到确认，也就不会连接了。

TCP连接的释放 - 四次挥手
1. 最开始的时候，客户端和服务器都是处于ESTABLISHED状态。客户端主动关闭连接，服务器被动关闭连接。
2. 第一次握手
  ○ 当客户端不需要发送数据时，发出连接释放报文，并且停止发送数据。
     连接释放数据报文首部中FIN=1，seq=u（u等于前面已经发送过的数据的最后一个字节的序号加1）
  ○ TCP协议规定，FIN报文段可以携带数据（因为连接还没断开），但即使不携带数据也要消耗一个序号
3. 第二次握手
  ○ 服务器收到连接释放报文，发出确认报文
     确认报文的首部中ACK=1，ack=u+1，seq=v
  ○ 此时，客户端已经没有数据要发送了，但是服务器可以继续发送数据，客户端依然接受
  ○ 客户端收到服务器的确认请求后，进入FIN-WAIT-2（终止等待2）状态，接受服务器发送的数据
4. 第三次握手
  ○ 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文
  ○ 连接释放报文的首部中FIN=1，ack=u+1，服务器之前很可能又发送了一些数据，可以假定此时的序列号为seq=w
  ○ 此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认
5. 第四次握手
  ○ 客户端收到服务器的连接释放报文后，发出确认报文
     确认报文的首部中ACK=1，ack=w+1，序列号为seq=u+1或seq=u+1+x，其中x为第一次握手时携带的字节数量
  ○ 第四次握手后TCP连接还没有释放，客户端必须经过2×MSL（Maximum Segment Lifetime最长报文段寿命）的时间后才撤销TCB并进入CLOSED状态
  ○ 服务器只要收到了客户端发出的确认报文，就撤销TCB并立即进入CLOSED状态
     因此服务器结束TCP连接的时间要比客户端早一些

为什么客户端最后还要等待2MSL？
1. 保证客户端发送的最后一个ACK报文能够到达服务器，因为客户端最后一个ACK报文可能丢失

• 站在服务器的角度看来，我已经发送了连接释放报文请求断开连接了，但客户端还没有给我回应，应该是没有收到我发送的连接释放报文，于是服务器又会重新发送一次。而客户端就能在这2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
• 如果客户端在发送第四次握手后不等待2MSL而直接进入CLOSED状态，若客户端的第四次握手丢失，则服务器不能进入正常关闭状态（以为客户端没收到第三次握手，所以重复发送第三次握手），而此时客户端已经关闭，也不可能再重传

2. 防止已经失效的连接请求报文段出现在本连接中

• 客户端发送完最后一个确认报文后，在这个2MSL时间中就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样新的连接中不会出现旧连接的报文

为什么建立连接是三次握手，关闭连接确是四次挥手？

• 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端
• 关闭连接时，服务器收到客户端的FIN报文时，仅仅表示客户端不再发送数据了但是还能接收数据，而服务器未必全部数据都发送给客户端了，所以服务器可以立即关闭，也可以发送一些数据给客户端后，再发送FIN报文给对方来表示同意现在关闭连接。
• 因此，服务器ACK和FIN一般都会分开发送，从而导致多了一次握手。