1. 计算机网络和因特网

1.1 什么是Internet？什么是协议？

首先从两个角度来回答什么是Internet：

1.具体结构描述

• 因特网是一个世界范围的计算机网络，即他是一个互联了遍及全世界数十亿计算设备的网络。这些设备都称为主机（或者叫端系统）
• 端系统通过因特网服务提供商（ISP）接入因特网
• 端系统通过通信链路和分组交换机连接到一起

2.服务描述 从为应用程序提供服务的基础设施角度来看：

• 现在的电子邮件、音乐、电影、在线视频等等，这些应用程序都涉及了相互交换数据的端系统，故称他们为分布式应用程序。
• 与因特网相连的端系统提供了套接字接口，该接口规定了运行在一个端系统上的程序请求因特网基础设施向运行在另一个端系统的特定目标程序交互数据的方式。

3.协议 端系统、分组交互及和其他因特网部件都需要运行一系列协议，这些协议控制因特网中信息的接受和发送。

• 协议定义了在两个或多个通信实体之间交换的报文的格式和顺序，以及报文发送和/或接受一条报文或其他事件所采取的行动。
• 因特网广泛的使用了协议，不同的协议用于完成不同的通信任务。

1.2 网络结构

网络的结构包括网络边缘、网络核心和接入网

1.2.1 网络边缘

上面我们了解了什么是主机，因为他们位于因特网的边缘，故称为端系统。

• 主机 = 端系统
• 主机有时进一步分为两类：客户和服务器

1.2.2 接入网

将端系统物理连接到其边缘路由器的网络

1.2.3 网络核心

由因特网端系统的分组交换机和链路构成的网状网络。通过网络链路和交换机移动数据有两种方式：电路交换和分组交换。

1.电路交换

在电路交换中，在端系统间通信会话期间，预留了端系统间的通信所需要的资源（缓存、链路传输速率）

2.分组交换

（1）过程

• 端系统彼此交换报文
• 源将长报文划分为较小的数据块，称之为分组（packet）
• 在源和目的地之间，每个分组都通过通信链路和分组交换机
• 交换机主要有两类：路由器和链路层交换机
• 分组以等于该链路最大传输速率的速度传输通过通信链路

（2）排队时延和分组丢失 当分组到达分组交换机时，发现链路正在传输其他的分组，他就需要进入等待的状态，也就是排队延时。因为缓存的位置有限，所以还可能出现分组丢包的情，也就是分组丢包况。

（3）转发表和路由选择协议 考虑到上面的过程后我们再思考一个问题，当分组千辛万苦来到了路由器，那么路由器他该向何处的链路进行转发呢？

• 每个端系统都具有一个IP地址
• IP地址是一种等级结构
• 每个路由器具有一个转发表，用于将 目的的地址（或目的地址的一部分）映射成为输出链路。
• 路由器检查该分组的目的IP地址的一部分，并向相邻的路由器转发改组

3.分组交换和电路交换的对比

• 分组交换不适合实时服务，如电话和视频服务，因为他端到端的时延是可变且不可预测的
• 但是分组交换提供了比电路交换更好的带宽共享
• 分组交换比电路交换更加简单、有效、成本更低

1.3 协议的层次结构及其服务模型

1.3.1 协议分层

网络设计者以分层 的方式组织 协议，实现了这些西医的网络硬件和软件。每个协议属于一个层次，我们再关注它向上一个层提供的服务，即所谓的一层服务模型。因特网的协议栈由五个层次组成 ：物理层、链路层、网络层、运输层和应用层。

1.应用层：

数据单元是报文，为用户和应用进程提供服务，包括协议：

• HTTP：web文档请求和传送
• SMTP：电子邮件报文的传输
• FTP：活化石，两个端系统之间的文件传输
• P2P：不同于前面的C/S模式
• DNS：域名解析，分布式数据库

2.运输层：

数据单元是报文段，在应用程序端点之间传送应用报文 。有两种传输协议：

（1）TCP

• 提供了面向连接的服务

（2）UDP

• 向应用程序提供了无连接服务，一种不提供不必要的服务的服务
• 没有可靠性、没有流量控制 、也没有拥塞控制

3.网络层：

端到端 ，数据单位是分组，可见上面的分组交换和电路交换 因特网的网络层 负责将称为数据报的网络层分组从一台主机转移到另一台主机

4.链路层：

点到点，传输的数据单位是帧

5.物理层：

数字数据和物理信号之间的转换，传输的数据单位是比特

2. 应用层

2.1 应用层协议原理

研发网络应用程序的核心是写出能运行在不同的端系统和通过网络彼此通信的程序。

• web应用中，两个互相通信的不同程序：
  • 一个是运行在用户主机上的浏览器程序
  • 另一个是运行在web服务器主机上的web服务器程序
• P2P文件共享系统，在参与共享社区的每台主机都有一个程序

2.1.1 网络应用程序体系结构

1. C/S体系结构

一个总是打开的主机称为服务器，它服务许多其他称为客户的主机的请求。

局限性：单独的服务器跟不上他左右客户请求的情况

2. P2P体系结构

P2P体系结构对于数据中心的专用服务器有最小的依赖，应用程序之间使用直接通信。它最引人入胜的特性之一就是自扩展性

局限性：面临安全性、性能和可靠性挑战

2.1.2 进程通信

用操作系统的话，进行通信的实际上是进程而不是程序。一个进程可以被认为是运行在一个端系统中的一个程序，两个不同端系统上的进程跨计算机网络交换报文而相互通信。

• 发送进程生成报文并向网络中发送
• 接受进程接受这些报文并通过回送报文进行响应

1.客户和服务进程

• 客户端进程：发起进程的一端
• 服务器进程 ：等待连接的进程

2.进程和计算机网络之间的接口

进程之间通过一个称为套接字（Socket）的软件接口向网络发送报文和从网络接受报文。

• 套接字是同一个主机内应用层与运输层的接口。
• 应用程序开发者可以控制套接字在应用端的一切，但是对于运输层几乎没有控制权限。除了可以：①选择运输层协议②设定几个运输层的参数

3.进程选址

• 主机由IP地址进行标识
• 为了发送至指定IP地址主机上的某个进程，还需要确定端口号。常见的web服务器默认端口是80端口

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

运输层协议为调用它的应用程序提供的服务可以分为四类：可靠数据传输、吞吐量、定时和安全

• 可靠数据，第一章讨论过分组交换的过程中可能出现分组的丢失，如果一个协议确保了数据的正确性、有序性、完整性等就认为提供了可靠数据传输 （1）邮件、文件传输、web文档传输等应用数据丢失会产生严重的后果 （2）音频、视频等能够承受一定量的数据丢失

• 吞吐量 ：两个进程之间交付比特的速率

• 定时：保证了在一定时间内完成数据的传输

• 安全性：顾名思义，就是进程中传输数据的保护

2.1.4 因特网提供的运输服务

1.TCP服务

（1）面向连接服务

• 面向连接服务：在进行报文流动前，TCP让客户和服务器互相进行交换运输层控制信息。
• 这个所谓的握手过程提醒客户和服务器，让他们为大量的分组的到来做好准备
• 一个TCP连接在两个进程的套接字之间建立后，双方可以在此连接上进行报文收发
• 当报文放松结束时，必须拆除该连接。

（2）可靠数据传送服务

• 通信进程之间依靠TCP能够无差错、按适当顺序交付所有的数据

（3）拥塞控制机制 在发送方和接收方之间的网络出现拥塞时，TCP拥塞控制机制会 一直发送进行。

2.UDP服务

UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。它是无连接的且提供不可靠数据传输。

3.安全性服务、吞吐量服务和定时服务

• 无论是TCP还是UDP都没有提供任何加密机制，所以因特网研制了TCP的加强版本成为安全套接字层（SSL）
  • 通过SSL提供了进程与进程之间的安全性服务，包括数据加密、数据完整性和端点鉴别
  • 注意SSL是对TCP的加强不是协议
  • SSL是在应用层上实现的
• 吞吐量服务和定时服务，虽然没有在运输协议中明确表明，但是如今的所有的设计尽可能的确保这两项服务。

2.1.5 应用层协议

应用层协议 定义了运行在不同端系统上的应用程序进程如何进行相互传递报文：

• 交换报文的类型
• 各种报文类型的语法
• 字段的语义
• 一个进程何时该如何发送报文，对报文进行响应的规则

2.1.6 网络应用

五种重要的网络应用：web、文件传输、电子邮件、目录服务、流式视频和P2P

2.2 HTTP协议

2.2.1 HTTP概述

1.概况

• HTTP：超文本传输协议
• C/S体系结构：web客户端和web服务器
• HTTP定义了web客户端向web服务器请求web页面的方式，以及服务器向客户端传送web页面的方式

2.运输服务

HTTP使用TCP协议作为他的支撑运输协议

• 客户发起一个与服务器的连接
• 一旦连接建立，浏览器和服务器间的进程可以通过套接字接口来访问TCP
• 客户通过套接字发送HTTP请求报文，从套接字接收HTTP响应报文
• TCP提供可靠的数据传输服务
• 服务器的响应报文完整的回到客户端

注意：HTTP是一个无状态协议，服务器向客户发送被请求的文件，不存储任何关于该客户的状态信息

2.2.2 非持续连接和持续连接

1.非持续连接的HTTP

客户和服务器间的每一个请求/响应都用一个单独的TCP连接发送

缺点：

• 必须为每一个请求对象建立一个全新的连接，客户和服务器中都要分配TCP缓冲区和保持TCP变量，给服务器带来严重负担
• 每一个对象都要经受两倍RTT的交付时延，一个RTT用于建立TCP，一个用于请求和接收一个对象

2.持续连接的HTTP

（1）持久连接（HTTP Persistent Connections，也称HTTP keep-alive）

在采用HTTP1.1持续连接的情况下，服务器在发送响应后保持TCP连接的打开，后续的请求报文和响应报文能够通过相同的TCP连接进行传送。

（2）管线化

持久的连接使得管线化成为可能——不需要等待下一个请求得到响应就可以进行下一次请求

2.2.3 HTTP报文的格式

访问 hackr.jp 时，请求报文的首部信息

1.HTTP请求报文

• 请求行：请求方法 + URI + 协议版本

  • 请求方法：GET、POST、PUT、HEAD、OPTIONS、TRACT、CONNECT、LINK、UNLINK

  方法	说明	支持的HTTP版本
  Get	获取资源	1.0、1.1
  POST	传输实体主体	1.0、1.1
  PUT	传输文件	1.0、1.1
  HEAD	获取报文首部	1.0、1.1
  DELETE	删除文件	1.1
  OPTIONS	询问支持的方法	1.1
  TRACK	追踪路径	1.1
  CONNECT	要求使用隧道协议连接代理	1.1
  LINK	建立和资源之间的联系	1.0
  UNLINK	断开连接关系	1.0

  • URI
    • 协议：http和https
    • 登录信息：可选，指定用户名和密码作为从服务器端获取资料的登录信息
    • 服务器地址：常见的URL，通过DNS解析成主机唯一的IP地址
    • 端口号：访问服务器的套接字，web服务器默认端口号是80
    • 带层次的文件路径：指定服务器上的特定文件路径获取资源
    • 查询字符：可选，对于已指定的文件路径内的资源可以使用查询字符串
    • 片段标识符：可选，标记出已获取资源中的子资源
  • 协议版本：http0.9、http1.0、http1.1

• 首部字段：见下

• 报文实体内容

2.HTTP响应报文

• 状态行：协议版本 + 状态码 + 状态码的原因短语

  • 协议版本：http0.9、http1.0、http1.1
  • 状态码：
    • 200 ok：正常处理了
    • 204 No Content：接受的请求已经成功处理，但是返回的响应报文中不含实体的主体部分
    • 206 Partial Content：该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求
    • 301 Moved Permanently：永久性重定向，表示请求得资源已经被分配了新的URI
    • 302 Found：临时性重定向，表示请求得资源已经分配了新的URI
    • 303 See Other：请求的资源存在着另一个URI，应使用GET方法定向获取请求的资源
    • 304 Not Modified：服务器允许访问资源，但是未满足条件的情况
    • 307 Temporary Redirect：临时重定向
    • 400 Bad Request：请求报文中存在着语法错误
    • 401 Unauthorized：需要有通过HTTP认真的认证信息
    • 403 Forbidden：请求资源被服务器拒绝了
    • 404 Not Found：服务器上无法找到请求的资源
    • 500 Internal Server Error：服务器在执行请求时出现了错误
    • 503 Service Unavailable：服务器超负荷或正在进行停机维护

• 首部字段：见下

• 主体

3.首部字段

• 通用首部字段

• 请求首部字段

• 响应首部字段

• 实体首部字段

2.2.4 cookie（HTML5：localStorage、sessionStorage）

1.cookie

前面我们知道HTTP服务器是无状态的。而 一个web网站通常希望能够识别用户，为此HTTP使用了cookie。

• 没有Cookie信息状态下的请求

  • 请求报文
  • 响应报文

• 存有Cookie信息状态下的请求

  • 请求报文

2.loaclStorage和sessionStorage

参考文章：localStorage 和 sessionStorage 简介

sessionStorage 和 sessionStorage 是 HTML5 新增的两个特性，这两个特性主要是用来作为会话存储和本地存储来使用的，解决了 cookie 存储空间不足的问题；

• localStorage

  • 允许访问一个Document源的对象Storage存取当前源的数据
  • 只能人为清除，否则一直存储在localStorage

• sessionStorage

  • 允许访问一个session Storage对象
  • 页面结束时清除，页面会话在浏览器打开期间一直保存

（1）相同点

• 存储大小5MB左右
• 同源策略，跨域无法访问
• 数据仅在客户端进行存储，不参与服务器的通信
• 以 key 和 value 的形式进行存储数据， value 值必须为字符串，不为字符串会自动转型( value 如果是对象则需要转为 json 进行存储)

（2）不同点

• localStorage只能人为清除，否则一直存储在localStorage；sessionStorage页面结束时清除，页面会话在浏览器打开期间一直保存
• localStorage只要在同一个浏览器可以共享数据，可以互相读取、覆盖、清除（注意同浏览器、同源）；sessionStorage的数据被限制在同浏览器、同源、同页面。

2.2.5 代理服务器：web缓存器

web缓存器也叫代理服务器，它能够代表初始web服务器来满足HTTP请求的网络实体。

2.2.6 基于HTTP追加的协议

因为HTTP协议的限制和自身的性能有限，而基于HTTP的web浏览器已经遍布全球。所以一些新的协议基于HTTP，在此基础上添加了一些新的功能。

1.消除HTTP瓶颈的SPDY

HTTP的一些标准，成为了实现web所需要功能的瓶颈。

• 一条连接上只可发送一个请求。
• 请求只能从客户端开始。
• 客户端不可以接受除响应以外的指令。
• 请求/响应未经压缩就发送。首部信息越多延迟越大。
• 发送冗长的首部。每次发送相同的首部信息造成浪费较多。
• 可以任意选择数据压缩格式。非强制压缩发送。

（1）Ajax（Asynchronous JavaScript and XML， 异 步 JavaScript 与 XML技 术）

Ajax是一种有效利用JavaScript和DOM的操作，以达到局部Web页面替换加载的异步通信手段。

• 核心技术：XMLHttpRequest的API，通过JavaScript脚本语言调用和服务器进行HTTP通信
• 优点：只更新一部分页面，响应中传输的数量会减少
• 问题：
  • 可能产生大量请求
  • 任未解决HTTP协议本身存在的问题

（2）Comet

一旦服务器端有内容更新了，Comet不会让请求等待，直接给客户端返回响应。这是一种通过延迟答应，模拟实现服务器端向客户端推送的功能。

• 原理：通常服务器接收到请求，在处理完毕后就会立刻返回响应。但是为了实现推送功能，Comet会先将响应置于挂起状态，当服务器端有内容更新的时候，再返回响应。因此，服务器端一旦有更新，就可以立即反馈给客户端。
• 优点：做到了实时更新
• 问题：
  • 为了保存响应，一次响应时间变长了，期间为了维护连接也会消耗更多资源。
  • 任然未解决HTTP协议本身存在的问题

（3）SPDY的设计与功能

在七层模型中，SPDY属于会话层，意在解决HTTP遇到的瓶颈 实现功能：

• 多路复用流：通过单一的 TCP 连接，可以无限制处理多个 HTTP 请求。所有请求 的处理都在一条 TCP 连接上完成，因此 TCP 的处理效率得到提高。
• 赋予请求优先级：SPDY 不仅可以无限制地并发处理请求，还可以给请求逐个分配优先 级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响 应变慢的问题。
• 压缩HTTP首部：压缩 HTTP 请求和响应的首部。这样一来，通信产生的数据包数量和 发送的字节数就更少了。
• 推送功能：支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送 数据，而不必等待客户端的请求。
• 服务器提示功能：服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源 之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不需要的请求。

（4）WebSocket：Web 浏览器与 Web 服务器之间全双工通信标准。

利用 Ajax 和 Comet 技术进行通信可以提升 Web 的浏览速度。但问题 在于通信若使用 HTTP 协议，就无法彻底解决瓶颈问题。WebSocket 网络技术正是为解决这些问题而实现的一套新协议及 API。

2.2.7 HTTPS

2.3 DNS协议

当从浏览器输入一个URL到浏览器渲染出页面中间经历了什么？这是一个常见的问题，答案如下：

• 如果没有输入完全，浏览器会帮你补齐你的协议号和端口。
• 接着浏览器分析这串地址的协议号，域名，端口。与高速缓存里存放的域名进行一一对比。
• 若相同，则直接拿到IP地址。
• 若不同，则去本地域名服务器寻找。有则拿到IP地址。
• 若还是没有，则直接去根域名服务器寻找。此时根域名服务器要么给出IP地址，要么指出该去往哪个域名服务器寻找。直到找到IP地址。这个过程叫做DNS解析。
• 拿到IP地址后，需要与之通信。于是，通过三次握手建立TCP连接。
  • 客户端发送一个包给服务端表示我想请求连接。
  • 服务端收到请求后，回发客户端一个包表示我已经确认收到你的请求。
  • 客户端再发送一个包，表示握手结束
• 客户端发送请求报文。
• 服务端处理请求报文发送响应报文。
• 浏览器收到响应报文，渲染进程开始渲染页面。
  • 解析HTML生成DOM树。
  • 解析CSS生成CSSOM树。
  • 将DOM树和CSSOM树合并在一起生成渲染树。
  • 遍历渲染树开始布局，计算每个节点的位置大小等信息。
  • 将渲染树每个节点绘制到屏幕。
• 浏览器渲染完成，通过四次挥手关闭连接。
  • 浏览器发送包，请求断开连接。
  • 服务端发送包给客户端，表示我已经收到你的请求。
  • 服务端再次发送包给客户端，表示我也想断开连接。
  • 客户端发送包给服务端，表示我已经收到你的关闭请求。接着就关闭连接，通信结束。

2.3.1 什么是DNS协议

识别主机有两种方式：IP地址和域名

• IP地址是一个有层次的数据，方便在网络中进行搜索
• 域名：是一个主机的名字，方便用户进行记忆

而DNS协议就是为了满足这两个的需求，通过域名解析协议（DNS，Domain Name System）来将域名和 IP 地址相互映射

后面四个问题在掘金上找了一篇写的不错的博客

2.3.2 域名和域名服务器

2.3.3 DNS的查询方式

2.3.4 DNS的缓存

2.3.5 完整域名解析过程

3. 运输层

运输层位于应用层和网络层中间，在因特网协议中，我们关注TCP和UDP协议

3.1 概述和运输层服务

• 运输层协议为运行在不同进程之间提供了逻辑通信。
• 应用进程通过使用运输层提供的逻辑通信功能彼此发送报文，无需考虑承载这些报文的物理基础设施的细节
• 运输层协议是在端系统实现的：
  • 发送端，运输层将从应用进程接收到的报文转换为报文段
  • 为每个报文段加上一个运输层首部，生成一个运输层报文段
  • 传递这些报文段给网络层
  • 网络层将其封装成数据包向目的地发送
  • 在接收端，网络层从数据包中提取运输层报文段，并将其提交给上层运输层
  • 运输层处理接收到的报文段
  • 将报文段中的数据为接受应用进程使用

3.1.1 运输层和网络层的关系

• 运输层位于网络层之上
• 网络层提供了主机之间的逻辑通信
• 运输层为主机之间不同进程之间提供了逻辑通信
• 运输层能提供的服务常常受制于网络层的服务
• 即使底层的网络层不能提供相应的服务，运输层协议也能提供某些服务

3.1.2 因特网运输层概述

先了解几个概念：

• 运输层的分组称为报文段
• 网络层的IP协议为主机之间提供了逻辑通信
• IP协议是不可靠服务，它的的服务模型是尽力而为交付服务，即不确保报文段的交付、不保证报文段的按序交付，不保证报文段中的数据的完整
• 每台主机都只有一个IP地址

1.UPD和TCP提供的服务模型

• 运输层的多路复用和多路分解
• 提供完整性检查

2.TCP额外提供的服务

• 可靠数据传输服务
• 拥塞控制

3.2 多路复用和多路分解

将网络层提供的主机到主机交付服务延伸到为运行在主机上的应用程序提供进程到进程的交付服务。

• 多路复用：在源主机从不同的套接字中收集数据块，为每个数据块加上首部信息从而生成报文段，将报文段发送给网络层
• 多路分解：接收端，运输层检查这些字段，标识出接收套接字，进而将报文段定向到该套接字。

3.3 无连接运输：UDP

3.3.1 UDP的特点

• 尽力而为的服务
  • 丢失
  • 乱序
• 无连接
  • UDP发送端和接收端之间没有握手
  • 每个报文段都被单独处理
• UDP的应用
  • 流媒体，对丢失不敏感，但是对速度敏感
  • DNS
  • SNMP

3.3.2 UDP报文段结构

存在的理由：

• 不建立连接，减少延迟
• 简单，没有连接状态
• 报文段头部开销小
• 无拥塞控制和流量控制，UDP可以尽快的发送报文段

3.3.3 UDP校验和

检测在被传输的报文段中的差错

3.4 面向连接的运输服务：TCP

3.4.1 TCP

概述 ：

• 点对点：一个发送方、一个接收方
• 可靠的、按顺序的字节流
• 管道化（流水线）：TCP拥塞控制和流量控制设置窗口大小
• 发送和接收缓存
• 全双工数据：数据是双向流动
• 面向连接：在传输前，先进行连接
• 有流量控制：发送发不会淹没接收方

1. TCP连接管理

参考文章：详解 TCP 连接的“ 三次握手 ”与“ 四次挥手 ”和 TCP 的 三次握手 四次握手

（1）TCP被称为是面向连接的，这是因为在一个进程给另一个进程发送数据之前，两个进程必须进行握手。即他们必须相互发送某些预备报文段，以建立确保数据传输的参数。也就是我们常说的三次握手：

• 客户端发送SYN，表明要向服务器建立连接。同时带上序列号ISN
• 服务器返回ACK（序号为客户端序列号+1）作为确认。同时发送SYN作为应答（SYN的序列号为服务端唯一的序号）
• 客户端发送ACK确认收到回复（序列号为服务端序列号+1）

1.为什么是是三次握手不是两次或四次？

因为，tcp连接是全双工的，数据在两个方向上能同时传递。所以要确保双方，同时能发数据和收数据

• 第一次握手：证明了发送方能发数据
• 第二次握手：ack确保了接收方能收数据，syn确保了接收方能发数据
• 第三次握手：确保了发送方能收数据
• 四次握手浪费，两次握手不能保证“双方同时具备收发功能”

2.为什么 客户端 最后还要发送一次确认？ 主要是为了防止已失效的连接请求报文段突然又传到了 服务器，因而产生错误。

（2）一旦建立起一条TCP连接，双方就能进程之间就可以相互发送数据了

• 客户进程通过套接字传递数据流
• TCP将这些数据引导到该连接的发送缓存（握手期间建立的）中
• TCP从发送缓存中取出一块数据，为其配上一个TCP首部，形成TCP报文段，将数据发送到网络层。
  • TCP规范没有明确提及TCP该 何时发送
  • MSS：TCP可以缓存中取出并放到报文段中的数据量

（3）所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。

• 主动关闭的一方发送FIN，表示要单方面关闭数据的传输
• 服务端收到FIN后，发送一个ACK作为确认（序列号为收到的序列号+1）
• 等服务器数据传输完毕，也发送一个FIN标识，表示关闭这个方向的数据传输
• 客户端回复ACK以确认回复

为什么挥手是四次而握手是三次？ TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？

• 建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。
• 释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

2.TCP报文段结构

• 源端口号、目的端口 ：用于多路复用和多路分解
• 32比特的序号字段和32比特的确认号字段：用于可靠数据传输
• 16比特的接收窗口字段：用于流量控制
• 4比特的首部长度字段：指示了TCP的首部长度
• 可选与变长的选项字段：发送发与接收方协商最大报文字段，或在高速网络环境下用作窗口调节因子时使用。
• 6比特的标志字段：
  • ACK：表示确认字段中的值是有效的
  • RST、SYN、FIN：连接、建立和拆除
  • CWR、ECE：在明确拥塞通告中使用了
  • PSH：被设置时表示接收方应该立刻将数据交到上层
  • URG：表示报文段里存在着被发送端的上层实体设置为“紧急”的数据
    • 紧急数据指针字段：紧急数据的最后一个字节

3.4.2 可靠数据传输的原理

1. rdt1.0 协议

首先考虑最简单的情况，底层通信道是完全可靠的

• 发送方
  • rdt_send(data)：接收来自较高层的数据
  • make_pkt(data)：产生一个包含该数据的分组
  • 将分组（packet）发送到信道中
• 接收端
  • rdt_rcv：从底层信道接受一个分组
  • extract(packet, data)：从分组中取出数据
  • deliver_data(data)：将数据传给较高层

2. rdt2.0 协议

第一种协议是在认为数据完全可靠下的情况，但是在实际模型中是分组中的比特可能受损的模型。

• 发送方

  • 状态1：
    • 发送端协议等待来自上层传输下来的数据
    • rdt_send(data)：接收来自较高层的数据，带有检验和
    • make_pkt(data)：产生一个包含该数据的分组
    • udt_send(sndpkt)：发送该分组
  • 状态2：
    • 等待来自接收方的ACK或NAK分组
    • rdt_rcv(rcvpkt) && isACK(rcvpkt)：表示接收方已经正确接收分组，状态转换成等待上层调用
    • rdt_rcv(rcvpkt) &&isNAK(rcvpkt)：表示上一个分组接收方的响应是重传，重新上传一遍分组并且等待和接收方回送的ACK和NAK

• 接收方

  • 分组没有受损，返回ACK
  • 分组受损，返回NAK

3. rdt2.1 协议

rdt2.0看似可以运行，但是有一个致命的缺陷，没有考虑到ACK或NAK受损的可能性。因此在rdt2.0基础上引入了序号。

发送方 接收方

4.rdt 3.0

除了比特受损外，我们再考虑计算机网络中出现的底层信道丢包的情况。

设置一个倒技术定时器

• 每次发送一个分组时便启动一个定时器
• 响应定时器中断
• 终止定时器

5.流水线

rdt3.0是一个功能正确的传输协议，但是他的停等协议（等待接收方返回的ACK后才能进入等待上层调用的状态）的特殊性能也造成了效率较低的问题。

解决办法：不以停等的方式运行，允许发送方发送多个分组，无需等待确认。这种技术称为流水线。

流水线带来的影响：

• 必须增加序号范围，因为每个分组必须有唯一的标识符
• 协议的发送发和接收方必须缓存多个分组
• 所需序号范围对缓冲的要求取决于数据传输协议如何处理丢失、损坏以及延时过大的分组。解决流水线差错恢复的两种基本方法是：回退N步（GBN）和选择重传（SR）

6.回退N步协议

回退N步协议（GBN协议，滑动窗口协议）：允许发送发发送多个分组不需要等待确认，但是未确认的分组数不能超过某个最大值N。

设置N的原因：流量控制、拥塞控制

GBK协议响应的三种事件：

• 发送方：

  • 当上层调用时
    • 窗口已满，告诉发送方等待一会
    • 窗口未满，产生一个分组并传送
  • 收到一个ACK
    • 窗口向右滑动
  • 超时事件
    • 如果收到一个ACK，但是前面的分组未被确认，重启定时器

• 接收方：

  • 序号为n的分组被正确接收到，并且按序，为n发一个ACK
  • 其它所有情况，接收方丢弃该分组，并选择最近序列的分组重新发ACK

7.选择重传协议（SR）

滑动窗口协议潜为了保证分组的正确顺序，对数据进行重传，但是考虑到窗口长度和带宽较大的情况，就会造成重复传递带来的效率问题。

选择重传：让发送发仅重传那些让它怀疑在接收方出错的分组，避免了不必要的重传。

8.TCP中的可靠数据传输

因特网的网络层服务（IP服务）是不可靠的，即不保证数据交付、不保证数据包按序交付、不保证数据包的完整。TCP在IP不可靠尽力而为的服务至上创建了可靠数据传输服务，确保了数据传输到另一端的是无损坏、无间隙、非冗余且按序交付的。

我们将根据前面的原理来解释TCP如何实现可靠数据传输的：

1. 如果来自下层的数据完全可靠，根据rdt1.0那么TCP协议只需要进行数据的传输即可。
2. 但是很可惜，网络传输过程中往往有比特的损失，于是根据rdt2.0，加上了校验和确保了数据的正确性
3. 看似上述协议已经完美，但是网络运输中还存在丢包的问题，根据rdt3.0，引入了计时器，当一个分组隔一段时间没有发过来，便重发一遍报文并重启计时器
4. 但是计时器还存在一个问题，如果响应报文只是延迟传过来，怎么与其他报文进行区分呢？于是引入了序号。这样接收方就可以根据数据的字节编号，得出这些数据是接下来的数据，还是重传的数据。
5. 根据rdt一些列的协议解决了可靠传输的问题，但是这是一种停等协议，就是说在传输的过程中，若未接收到报文的响应，上层应用就要一直等待，这样的工作效率太低。于是引入流水线的工作方式，运行多个报文发送，不用去等待响应报文后再继续发送。
6. 网络中充斥着和发送数据包一样数据量的确认回复报文，因为每一个发送数据包，必须得有一个确认回复。提高网络效率的方法是：累积确认 。接收方不需要逐个进行回复，而是累积到一定量的数据包之后，告诉发送方，在此数据包之前的数据全都收到。例如，收到 1234，接收方只需要告诉发送方我收到4了，那么发送方就知道1234都收到了。
7. 累计确认提高了网络效率，但是出现丢包的话采用的是GBN方法，即将从丢包的那个报文开始全部重传，这样做虽然保证了报文的有序性，但是一旦带框和流量大的话就会造成严重的资源浪费。所以在TCP报文的选项字段，可以设置已经收到的报文段，每一个报文段需要两个边界来进行确定。这样发送方，就可以根据这个选项字段只重传丢失的数据了。这种方法看起来很像SR协议，所以我们说TCP协议的可靠数据传输的差错恢复机制是GBN协议和SR协议的混合体。
8. 发送是否可以无限发送直到把缓冲区所有数据发送完？不可以。因为需要考虑接收方缓冲区以及读取数据的能力。如果发送太快导致接收方无法接受，那么只是会频繁进行重传，浪费了网络资源。所以发送方发送数据的范围，需要考虑到接收方缓冲区的情况。这就是TCP的流量控制 。解决方法是：滑动窗口 。

3.4.3 拥塞控制的原理

参考文章：浅谈 TCP 拥塞控制算法和TCP拥塞控制：数据包守恒、慢启动、拥塞避免、快重传

TCP 通过维护一个拥塞窗口来进行拥塞控制，拥塞控制的原则是，只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。

TCP 拥塞控制算法发展的过程中出现了如下几种不同的思路：

• 基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减小，如 Reno、Cubic 等。

• 基于时延的拥塞控制：将时延增加视为出现拥塞，延时增加时增大拥塞窗口，延时减小时减小拥塞窗口，如 Vegas、FastTCP 等。

• 基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如 BBR。

• 基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法形成一个控制策略，如 Remy。

拥塞控制算法的核心是选择一个有效的策略来控制拥塞窗口的变化