Computer Networking阅读笔记

Computer Networks and the Internet

What is the internet

1. 计算机网络中，我们把所有连入网络的设备叫做主机(hosts)或者端系统(end systems)，端系统一般可以分成两大类：clients和servers
2. 端系统之间由通信链路(communication links)和分组交换机(packet switches)连接。常见的通信链路包括同轴电缆，铜线，光纤和无线电频谱。常见的分组交换机有路由器(router)和链路层交换机(link-layer switch)
3. 家用路由器与计算机网络中的路由器的区别： https://www.zhihu.com/question/52176116

The network edge

Access Networks

1. 接入网指将端系统物理连接到边缘路由器(edge router，即路径上第一台路由器)的网络。接入网按照使用环境主要分为家庭，公司和广域移动无线。
2. 家庭接入网中比较流行的有数字用户线(Digital Subscriber Line, DSL)和同轴电缆。
3. 数字用户线技术使用电话线传输网络信号，采用频分复用技术(分为三个频率的信道，电话使用0到4kHz低频，网络数据使用4kHz到50kHz中频或50kHz到1MHz高频)，因此在用户端需要一个DSL调制解调器(DSL Modem)，将网络数据的数字信号转换成高频电信号，这样才能和低频电话信号一起通过电话线发送。电话公司端需要使用数字用户线接入复用器(DSLAM)分离数据信号与电话信号，并发送到各自的网络中。
4. 同轴电缆技术使用电视线传输网络信号，与数字用户线技术类似，同轴电缆在用户端也需要使用调制解调器(cable modem)，在电视服务商端也需要区分电视信号与网络信号。
5. 除了以上两种技术，常见的家庭接入网还有光纤入户，拨号上网与卫星信号
6. 公司接入网与家庭接入网的区别是公司通常将一个局域网连接到边缘路由器，也就是说公司的一个局域网可能连接有多个端系统，随后这个局域网在连接到边缘路由器以获得互联网连接。比较常见的局域网有以太网(Ethernet)和WiFi。
7. 以太网的用户(端系统)通过双绞铜线连接到以太网交换机，以太网交换机再与因特网相连；WLAN(wireless LAN)的用户(端系统)与接入点进行数据收发，接入点与企业网连接(很有可能使用了有线以太网)，企业网再与因特网相连。基于IEEE802.11技术的WLAN被通俗的称为WiFi。
8. 虽然以太网与WiFi最初是设置在企业或大学中的，但近来许多家庭将接入网与廉价的无线局域网技术结合起来，来产生强大的家用网络。 我们家里的路由器能生成一个小的局域网，这个局域网通过调制解调器连接到互联网。

Phsical Media

1. 常见的物理媒介有：双绞铜线，同轴电缆，光纤，陆地无线电信道和卫星无线电信道

The network core

Packet Switching

1. 在不考虑传播时延的情况下，分组传播的速度由分组的大小(L bit)和链路最大传输速率(R bit/s)决定，从链路的一端传到另一端需要L/R秒

Store-and-Forward Transmission

1. 分组交换采用存储转发运输(Store-and-Forward Transmission)。存储转发运输指的是分组交换机(packet switches)在开始发送某个分组的第一个比特前，必须已经接收到整个分组。假设我们要从A发送一个L bit大小的分组到B：A->router->B。从A到router与从router到B的通信链路的传输速度都是R b/s。如果没有存储转发运输，那么从A到B的时延就是分组的大小除以链路的传输速度，也就是L/R。但是如果考虑存储转发运输，那么分组必须先到达router，直到所有bit全部到达以后，才可以继续转发到B，所以时延是2L/R。
2. 因此，在考虑存储转发运输的情况下，如果有N个通信链路(其中有N-1个router)，那么最后的时延就是NL/R

Queuing Delays and Packet Loss

1. 每台分组交换机有多条链路与之相连。对于每条相连的链路，该分组交换机都有一个输出缓存(output buffer)，它用于储存分组交换机准备发往这个链路的分组。如果一个到达的分组发现想要发送到的链路正在被别的分组占用，那么它就会被储存在这个输出缓存中。因此除了上面提到的存储转发时延，分组交换也存在排队时延。
2. 如果一个分组在到达输出缓存的时候缓存已经满了，那么就会出现分组丢失(packet loss)，也就是丢包现象。

Forwarding Tables and Routing protocols

1. 前面我们提到过，一个路由器可能连接有多条输出链路，那么路由器如何决定选择哪条链路呢？答案是分组的头部包含目的地的IP地址，而路由器具有一个转发表(forwarding table)，可以将目的地址映射成输出链路。
2. 那么转发表是如何设置的呢？答案是由路由选择协议(routing protocol)自动设置的

Circuit Switching

1. 除了分组交换以外，另一种常见的数据传递方式是电路交换，电路交换与分组交换的区别是电路交换会预留端系统间沿路径通信所需要的资源(缓存，链路传输速度等)，而分组交换不会，分组会按需使用这些资源，其后果是有可能需要进入buffer排队等待。我们常用的电话就是电路交换的代表，电话的“占线”就是电路交换的象征。

Multiplexing in Circuit-Switched Networks

1. 电路交换网络中的复用技术包括频分复用(Frequency-Division Multiplexing, FDM)和时分复用(Time-Division Multiplexing, TDM)

Packet Switching Versus Circuit Switching

1. 分组交换比电路交换效率更好，具体的例子见书

A Network of Networks

1. 用户->接入ISP(Access ISP)->区域ISP(Regional ISP)->第一层ISP(Tier 1 ISP)。较低层的ISP与较高层的ISP相连，较高层的ISP彼此互联。用户和内容提供商是较低层ISP的客户，较低层ISP是较高层ISP的客户。

Delay, Loss and Throughput in Packet-Switched Networks

Overview of Delay in Packet-Switched Networks

1. 分组在从一个节点到另一个节点的过程中会经受几种不同类型的时延，主要有节点处理时延(nodal processing delay)，排队时延(queueing delay)，传输时延(transmission delay)和传播时延(propagation delay)，这些时延总体累加起来是节点总时延(total nodal delay)

Processing Delay

1. 节点处理时延指的是分组在到达节点后，节点处理该分组并继续发送所用的时间，比如router或者switch检查分组的头部来决定该分组该发送到那里的时间，或者router对分组进行字节校验所用的时间

Queueing Delay

1. 排队时延是指由于分组所要发往的链路正在被占用，该分组在buffer中排队等待发送的时间

Transmission Delay

1. 传输时延即是我们前面提到的L/R，也就是将所有分组发射到链路所需要的时间

Propagation Delay

1. 传播时延指的是分组在进入链路后，从一端传播到另一端所用的时间，如果链路的长度是d，分组在链路中传播的速度是s(一般是光速或略小于光速)，那么传播时延就是d/s

Comparing Transmission and Propagation Delay

1. 传输时延与传播时延看起来很容易搞混，但在明白其中原理后就很容易分清。由于物理媒介的传输能力是有限的，每秒所能进入物理媒介的数据也就是有限的，如果我们有一个L bit的分组，而链路的最大传输能力只有R bit/s，那么意味着我们需要L/R秒才能把这个分组的所有bit都发射到链路中，这就是传输时延。当分组的最后一个bit进入到链路中后，它需要以接近光速的速度发送到下一个node，这个时间也就是传播时延。所以说传播时延发生在传输时延之后。
2. 节点总时延(total nodal delay) = 节点处理时延(nodal processing delay)+排队时延(queueing delay)+传输时延(transmission delay)+传播时延(propagation delay)

Queuing Delay and Packet Loss

1. 我们假设a代表分组到达某个节点队列的平均速率(packets/s)，假设每个分组都有L bits，R(bit/s)为传输速率(即从队列中推出bits的速度)，那么我们可以得到一个流量强度(traffic intensity)的表达式：La/R
2. La/R越接近0，代表排队时延越小；La/R越接近1，代表排队时延越大，并且离1越近，时延上升的越快；La/R大于1，则bit到达队列的平均速率超过从该队列传输除去的速率，那么这个队列趋向于无限增加，我们应该避免着这种设计。
3. La/R并不能完全代表排队时延，因为a只是一个平均速率，现实生活中的流量都是不规则的，有可能在短时间的内遇到很大的流量，那么排队时延就会很大

End to End Delay

1. 前面我们讨论的都是一个节点上的时延，那么对于从源到目的地的时延(假设源主机与目的主机之间有N-1台路由器，并假设网络此时无堵塞，即没有排队时延)，那么：端到端时延 = N(节点处理时延(nodal processing delay)+传输时延(transmission delay)+传播时延(propagation delay))

Traceroute

End System, Application, and Other Delays

1. 除了上面提到的节点总时延，端到端还存在其他的时延，比如端系统中可能有一些其他的时延。

Throughput in Computer Networks

数据吞吐量指的是在用户端，我们每秒可以接收到的比特数。在没有其他用户干扰的情况下，从一个主机到另一个主机的数据吞吐量取决于数据流过的链路中最小的传输速率，即吞吐量=min{R1, R2， R3…}。如果存在其他用户干扰(干扰流量)，那么由于需要和其他用户共享吞吐量，那么吞吐量就会相应减少

Protocal Layers and Their Service Models

Layered Architecture

1. 在讨论网络的分层前，书中有一个很好的将复杂系统分层的例子：航线功能。
   票务层： 票务购买 票务投诉
   行李层： 行李托运 行李认领
   登机口层： 登机口登机 登机口离机
   起飞/着陆层： 起飞 着陆
   飞行层： 按路线飞行 按路线飞行
   从图中我们观察到：1. 每个层次与它下面所有的层次结合在一起，实现了某些功能(服务)。比如在行李层及以下，实现了人和行李从行李托运到行李认领的转移；在登机口层及其以下，实现了人和行李从离岗登机口到到港登机口的转移，但登机口层的服务仅对完成了上两层的乘客有效。2. 每个层次的功能是通过结合在本层中执行某些的动作和使用直接下层提供的功能来达到的。行李层的功能是通过本层中执行某些的动作(行李托运/认领)和使用直接下层提供的功能(登机口层的功能)来达到的
2. 利用分层的方式，我们可以将复杂的问题解耦并实现模块化，只要某个层的功能不改变，那么不论该层功能的实现方式如何改变，都不会影响整个系统。比如有一天登机口层不再按照头等舱->经济舱的顺序登机，而是按照身高登机，即我们对该层登机这一功能的实现方式进行了改变，结果是登机的功能以及其它层完全没有受到影响，乘客还是正常的进行了登机。

Protocal Layering

1. 网络的实现与前面的例子是类似的，网络的设计者以分层的方式组织协议以及实现这些协议的网络硬件和软件。同样的，每次通过在该层中执行某些动作或使用直接下层的服务来提供服务，例如由第n层提供的服务可能包括报文从网络的一边倒另一边的可靠交付，这可能是通过第n-1层的边缘到边缘的不可靠报文传送服务，加上第n层的检测和重传丢失报文的功能来实现的。
2. 一个协议层能够用软件，硬件或两者的结合来实现。诸如HTTP和SMTP这样的应用层协议几乎都是在端系统中用软件实现的，运输层协议也是如此。因为物理层和数据链路层负责处理跨越特定链路的通信，它们通常在与给定链路相关联的网络接口卡中实现。网络层经常是硬件与软件的的混合体。
3. 应用层：应用层是与我们人类打交道的地方，负责把人类的语言转化可以在端系统间传输的信息。应用层协议主要包括HTTP，SMTP和FTP。DNS服务也是基于应用层的协议。应用层协议分布于多个端系统上，一个端系统中的应用程序使用协议与另一个端系统中的应用程序交换信息分组，这样的信息分组我们叫做报文(message)。
4. 运输层：应用层将人类的语言转化为可传输的信息后，运输层负责在应用程序端点之间传送应用层报文。运输层有两种协议：TCP和UDP，它们都可以运输应用层报文。区别是TCP是一种面向连接的服务，确保应用层报文能够发送到目的地，并提供了流量控制和拥塞控制。UDP提供无连接服务，没有可靠性，也没有流量控制和拥塞控制。运输层的分组我们叫做报文段(segment)。
5. 网络层：运输层提供在应用程序间的报文段运输，但是应用程序是跑在主机上的，负责由报文段有一个主机移动到另一个主机是由网络层来负责的。网络层有著名的IP协议，所以实现了网络层的因特网组件都必须运行IP协议，同时路由选择协议也属于网络层。网络层的分组我们叫做数据报(datagram)
6. 数据链路层： 网络层负责在主机间传送datagram，但是这一过程中会经过很多条通信链路，在通信链路上如何运输是由数据链路层负责的。链路层协议包括以太网，WIFI等。链路层的分组称作帧(frame)。
7. 物理层： 链路层的任务是将整个frame从一个网络节点移到下一个网络节点，物理层的任务是将该frame中的一个个比特从一个节点移动到下一个节点。比如，以太网具有很多物理层协议，有关于双绞铜线的，有关于同轴电缆的。

The OSI model

1. 除了因特网五层协议栈，还有OSI七层协议栈。OSI在应用层和运输层之间增加了表示层和会话层。

Encapsulation

1. 书中的图1-24展示了封装的原理，也就是每一层的分组通常由两部分封装：首部字段和有效载荷字段(payload field)，首部字段是本层增加的信息，有效载荷字段来自于上一层。比如运输层向网络层传递报文段，网络层会在头部添加源和目的端系统地址等IP信息。
2. 由图中还可以看出，网络中的路由器实现了1-3层，也就是物理层到网络层，所以路由器可以使用IP地址寻址和路由；链路层交换机只实现了1-2层，也就是物理层和数据链路层，所以交换机是不能进行识别IP地址并路由的，但是它可以识别以太网地址。

Application Layer

Principles of Network Applications

1. 网络应用程序(软件)运行在端系统(网络边缘)上，它不能也不允许运行在网络核心(交换机和路由器)上，因为这些网络核心不包括应用层，他们往往只有网络层及其以下的层。

Network Application Architectures

1. 网络应用程序主要分为两种架构：客户-服务器架构(client-server architecture)，对等(P2P)架构(peer-to-peer architecture)
2. 客户-服务器架构有一个一直运行的服务器，服务器有一个固定的IP地址。所有向服务器发出请求的端系统叫做客户，客户与客户之间不会直接交流。
3. P2P架构是一种去中心化的架构，peer之间直接交流传递信息，没有客户和服务器之分。
4. 很多应用混合了两种架构模式，比如很多实时聊天应用，服务器会跟踪客户的IP地址，但是客户之间的信息是直接互相传递的(不经过服务器)

Processes Communicating

1. 在构建网络应用程序前，还需要对运行在多个端系统上的程序是如何互相通信的有所了解。用操作系统的术语来说，进行通信的实际上是进程(process)而不是程序。当多个进程运行在相同的端系统上时，它们使用进程间通信机制相互通信，而对于网络应用程序，我们需要的是运行在不同终端上的进程间的通信。
2. 在一对进程之间通信的场景中，发起通信的被认为是客户(client)，在会话开始时等待联系的进程是服务器(server)
3. 报文从一个进程(应用层)发送到另一个进程(应用层)，需要经过下面的各种网络分层，进程是通过一个叫做套接字(socket)的软件接口向网络发送报文的。我们可以把套接字类比成门，进程是一所房子，当我们想要从房子中邮递一个包裹时，都需要先经过房子的门。套接字就是应用层和运输层之间的一层接口，当我们通过套接字发送一段报文后，我们就默认这段报文已经进入运输层了，剩下的事情就不是应用层需要考虑的了。
4. 应用开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。应用程序开发者对于运输层端的控制仅限于：1.选择运输层协议 2.也许可以设定几个运输层参数，比如最大缓存和最大报文长度。
5. 一台端系统可以有多个进程在运行，那么如何区分哪个进程是在进行通信的那个呢？答案是使用端口号(port number)。所以IP地址加上端口号才能确定通信的真正地址。

Transport Services Provided by the internet

1. TCP是一种面向连接的运输层协议。这种连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。同时TCP提供可靠地数据传送服务，通信进程能够依靠TCP无差错并按照相应顺序交付所有发送的数据。另外TCP还提供拥塞控制机制
2. UDP是一种不提供不必要服务的轻量级运输协议。UDP是无连接的，并且不提供可靠数据传送服务，也就是说UDP协议不保证报文能到达接收进程，不仅如此，即使到达接收进程的报文也可能是乱序到达的。

Application-Layer Protocols

1. 上面我们讨论了进程间通过套接字发送和接收报文进行通信，但是如何构造这些报文？在这些报文中的各个字段的含义是什么？进程何时发送这些报文？这些都是由应用层协议定义的。
2. 应用层协议定义了：1.交换的报文类型，例如请求报文或者响应报文 2.各种报文类型的语法，如报文中的各个字段及这些字段的描述 3.字段的语义，即这些字段中信息的含义 4.确定一个进程何时以及如何发送报文，对报文进行响应的规则

The Web and HTTP

Overview of HTTP

1. Web页面(也叫做文档, document)是由很多对象组成的，一个对象通常是一个HTML文件，一个JPEG图片或者一段视频。通常一个Web页面会有一个HTML基本文件(base HTML file)和很多引用对象，也就是说在这个HTML基本文件中嵌入了很多其他的对象的引用。
2. URL：http://www.someSchool.edu/someDepartment/picture.gif。http://www.someSchool.edu是主机名，/someDepartment/picture.gif是路径名
3. HTTP协议使用TCP协议作为它的运输层协议，当我们把一个HTTP请求通过套接字发送到TCP一段以后，HTTP协议就不再管这个请求时如何发送到另一端的，这些完全是由底层的分层来处理的。从这里我们就看出了分层的好处：HTTP不需要考虑是否会丢失数据或者数据的顺序问题，这些一律由下面的TCP层来考虑，应用层只需要按照HTTP协议将请求从套接字发送出去就好了。
4. HTTP协议是一种无状态协议，即使我们向某个服务器短时间内发送相同的请求，服务器也不会说相同的东西已经返回过了，相反的，服务器会完全忘掉之前的请求，每次收到新的请求都会重新返回。

Non-Persistent and Persistent Connections

1. TCP是一种面向连接的运输层协议，在建立连接时需要先进行三次握手。那么一个问题来了：当我们使用HTTP协议获取一个Web页面的多个对象的时候，是每次都建立一个新的TCP连接，还是只使用一个建立好的连接？这其实就引出了HTTP的两种连接方式：非持续连接和持续连接。HTTP既可以使用非持续连接，也可以使用持续连接，虽然HTTP默认使用的是持续连接，但是在客户端和服务器端也是可以配置成非持续连接的。
2. 如果我们采用非持续连接，从服务器向客户传送一个Web页面的步骤会是这样的(假设该页面含有一个HTML基本文件和10个JPEG图片，并且这11个对象位于同一台服务器，该HTML基本文件的URL为http://www.someSchool.edu/someDepartment/home.index)：
   • HTTP客户进程向服务器www.someSchool.edu的80端口发起一个TCP连接
   • HTTP客户经过套接字发送一个HTTP请求报文，该请求报文包含了路径名/someDepartment/home.index
   • HTTP服务器经过它的套接字收到该请求报文，从其存储器(RAM或磁盘)中检索出目标对象，封装成一个HTTP响应报文，并通过套接字发送
   • HTTP服务器进程通知TCP断开该TCP连接(但是TCP直到确认客户已经完整的收到响应报文时，它才会实际中断连接)
   • HTTP客户接收响应报文，TCP连接关闭。分析报文发现里面还有其他十个对象的引用
   • 对每个JPEG图片对象重复前四个步骤
3. 我们定义RTT是一个分组从客户到服务器再返回的时间，由于TCP连接需要进行三次握手，所以传递一个Web对象所需的时间大概是2RTT+传输Web对象所用的时间
4. 由上面我们可以看出非持久连接有两个缺点：1.过多的连接会加重服务器的负担 2.每建立一个TCP连接都需要2RTT的时延，这样导致时延增大
5. 对于HTTP1.1的持续连接来说，一个TCP连接可以发送多个Web对象请求，这些请求可以一个接一个的发出，而不必等待未决请求的回答

HTTP Message Format

HTTP Request Message

1. HTTP请求的基本格式可以参照书中的图片，分为请求行(Request line), 首部行(Header lines), Entity body。一个例子如下：

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

2. 第一行是request line，request line有三个部分组成：the method field，the URL field，HTTP version field。
3. 接下来四行是header lines。Host说明了我们想要请求的Object所在的主机，这个看起来没用，因为我们已经建立了客户到服务器的TCP连接，但是这个header在web proxy的时候是有用的；Connection:close的意思是这个HTTP请求使用非持久连接；User-agent说明了客户端使用的的浏览器类型，这个header的作用在于服务器会根据客户浏览器类型的不同来发送不同形式的同一个web对象；Accept-language代表用户想要一个法语版本的web对象，如果没有的话服务器会发送一个默认版本。
4. 上面的例子我们使用的是GET方法，如果使用POST方法的话，可以在Entity body部分放入想要发送的数据，需要注意的是Header lines和Entity body之间有一个空行。
5. HTTP的请求主要有GET, POST, HEAD, PUT, DELETE。HEAD与GET类似，但不会返回请求的web对象；PUT常用于上传；DELETE常用于删除

HTTP Response Message

1. HTTP响应的基本格式可以参照书中的图片，分为状态行(Status line)，首部行(Header lines)，Entity body。一个例子如下：

   HTTP/1.1 200 OK
   Connection: close
   Date: Tue, 18 Aug 2015 15:44:04 GMT
   Server: Apache/2.2.3 (CentOS)
   Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
   Content-Length: 6821
   Content-Type: text/html
   
   (data data data data data ...)

2. 第一行是status line，由三个部分组成：the protocal version field, a status code, a corresponding status message。这个例子中使用的是HTTP 1.1版本，请求一起正常。
3. Connection: close告诉客户TCP连接将被断开在发送完报文以后；Date显示HTTP请求建立的时间，注意这个时间不是web对象创建或者最后一次修改的时间，而是服务器从系统中获取该web对象并发送出去的时间；Server显示报文是由一个Apache服务器发出去的；Last-Modified会在后面的web proxy部分讲解；Content-Length显示web对象含有多少bytes；Content-Type显示web对象时HTML文档
4. 常见的HTTP状态码： 200 OK(请求成功，请求的信息包含在响应中)；301 Moved Permanently(请求的对象已经过被永远移走了，新的URL在Location这个Header那里，客户的软件会自动去获取新的URL)；400 Bad Request(服务器无法理解请求)；404 Not Found(请求的对象不存在于服务器中)；505 HTTP Version not Supporter(HTTP版本不支持)
5. 除了上面我们提到的首部行，还有其他许多的首部行，客户或者服务器端根据相应的配置来增加需要的首部行

User-server Interaction: Cookies

1. 前面我们提到过，HTTP协议是一种无状态(stateless)的协议，但是很多时候网站需要识别用户，比如在购物网站将物品接入购物车，我们希望下一次打开这个网站的时候，购物车里的物品仍旧存在。开发者为了实现中断和继续等操作，将user agent和server之间一对一的交互，抽象为“会话”，进而衍生出“会话状态”，也就是session的概念。session的相关信息会储存在服务器端，客户与服务器之间传递这个session信息可以使用cookie技术。
2. Cookie技术由四部分组成：1)HTTP响应中一个cookie首部行 2)HTTP请求中一个cookie首部行 3)一个保存在客户端并由浏览器管理的cookie文件 4)网站端用于存储cookie的后端数据库
3. 下面我们用在亚马逊购物的例子来讲解cookie的原理： 当我们第一次访问亚马逊网站的时候，亚马逊将我们的请求识别为新的用户，并创建一个唯一识别码(session ID)，并且在HTTP响应中加入Set-cookie首部行，比如：Set-cookie: session-id=1678。当我们的浏览器收到这个HTTP响应后，发现里面有一个Set-cookie首部行，于是在他管理的cookie文件的最后面加上新的一行，这一行包括这个服务器的域名和返回的唯一识别码。随后当我们的浏览器再次访问亚马逊网站的时候，浏览器查询到cookie文件中有相应的cookie识别码，于是在以后所有对亚马逊网站的HTTP请求中都加入Cookie: 1678首部行。亚马逊服务器收到HTTP请求并根据相应的cookie唯一识别码，可以知道所有我们之前在网站中的活动情况。虽然网站不知道我们是谁，但是对我们的活动一清二楚，如果以后我们在亚马逊注册了账号，这个session ID也就会和账号绑定在一起，亚马逊也就知道我们所有的历史活动
4. Session与cookie：https://www.zhihu.com/question/19786827. 总结来说，session是服务器端保存的一个数据结构，用来跟踪用户的状态，Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session信息交互的一种方式，Cookie技术完全可以用来保存一些别的信息，而不只是保存session信息。

Web Caching

1. web缓存器，也叫做代理服务器，是介于客户与服务器之间的一个中间服务器。web缓存器有自己的磁盘存储空间并且后保存最近请求过的对象的副本。所有的浏览器都可以配置成先定向到某个web缓存器。
2. 如果我们将浏览器设置了代理，并且请求对象http://www.someschool.edu/compus.gif，那么将会发生：
   • 浏览器创建一个TCP连接到web缓存器，并向web缓存器中的对象发送一个HTTP请求
   • web缓存器进行检查，看看本地是否存储了该对象副本。如果有，web缓存器就向客户浏览器用HTTP响应报文返回该对象
   • 如果web缓存器中没有该对象，它就打开一个与该对象的初始服务器的TCP连接并请求该对象。初始服务器向微博、缓存器返回含有该对象的HTTP响应
   • web缓存器收到该对象后，在本地储存一份副本，并向客户返回这个对象
3. 公司或者学校一般会安装代理服务器，这样如果有相同的请求发送到代理服务器上，那么代理服务器可以直接返回，不需要再去请求原服务器，这样减少了不必要的网络流量并且减少了响应时间(书中有一个对于有无web缓存器的响应时间的比较)，而且一般公司或者学校服务器的局域网比起互联网有较大的带宽。
4. web缓存器有很多的好处，但是缓存的一个重要问题就是缓存的对象是否没有过期。这里web缓存器使用一种conditional GET请求。我们知道web缓存器会保存一份对象的副本，同时它也会保存从服务器收到的Last-Modified首部行，当有相同的请求到达web缓存器的时候，web缓存器会先向原服务器发送一个conditional GET请求，也就是在这个HTTP请求中后加入一个If-modified-since的首部行，这个If-modified-since首部行的值就是之前web缓存器储存的Last-Modified首部行的值。服务器收到conditional GET请求后，会比较本地的对象最后改动的时间与If-modified-since首部行的值，如果对象在这个值之后进行了改动，那么就会返回一个200 Success并附上新的对象；如果没有改变，会返回一个304 Not Modified并且entity body为空，web缓存器在收到304后知道可以安全的使用现有的缓存。我们使用的web浏览器都自带缓存功能。
5. 上面提到的是正向代理，现在还有流行的反向代理技术。正向代理所代理的是客服端，也就是代理服务器在客户一端进行代理与缓存；反向代理代理的是服务器端，也就是代理服务器在服务器一端进行代理与缓存，这里书中没有介绍，后面自己要进行深入学习。

Electronic mail in the Internet

1. 电子邮件系统由三部分组成： 用户代理(user agent)，邮件服务器(mail server)，简单邮件传输协议(Simple mail Transfer Protocal, SMTP)。我们用Alice给Bob发邮件来举例说明邮件系统是如何运作的：Alice和Bob都各有一个用户代理，各自的用户代理也都使用各自的邮件服务器，当Alice在用户代理端编辑好邮件后，邮件先被发送到Alice端的邮件服务器，Alice短的邮件服务器尝试使用SMTP协议发送邮件到Bob端的邮件服务器，Bob的用户代理尝试从Bob端的邮件服务器取得邮件。

SMTP

1. SMTP使用TCP作为底层传输协议，邮件从发送方服务器使用SMPT建立一个TCP连接到接收方服务器，SMTP不会使用中继服务器，即使两个email服务器在地球的两端，它们也会直接建立TCP连接。
2. SMTP使用持续连接
3. 书中有关于使用SMTP协议命令建立握手的例子，后面应该使用telnet进行实践操作
   文章的方法实现了SMTP发邮件：https://stackoverflow.com/questions/1516754/connecting-to-smtp-gmail-com-via-command-line, 中间有一个报错(535-5.7.8 Username and Password not accepted.)，原因是需要去google账号里允许安全性较低的应用访问4. 使用telnet练习书中电子邮件的例子 telnet并不能连接现代email service因为现代email都是基于SSL的。按照这篇

Comparision with HTTP

1. HTTP是pull protocol，TCP连接是由想要拉取信息的客户端建立的；SMTP是push protocal，TCP连接是由发送方服务器建立的
2. SMTP只支持7位ASCII码，HTTP没有这个限制

Mail Message Format

1. 当使用SMTP协议命令建立好连接后，我们可以发送邮件的内容，邮件的内容包括body和headers，两者之间用一个空行隔开。常见的headers如下：

   From: alice@crepes.fr
   To: bob@hamburger.edu
   Subhect: Searching for the meaning of life

Mail Access Protocols

1. 90年代以前，接收方客户代理是直接登录到接收方邮件服务器去查看邮件的，因为SMTP是一个push请求，接收方需要的是一个pull请求，所以这个过程不能使用SMTP协议。相反的从发送方代理到发送方服务器是一个push请求，所以使用的是SMTP协议。
2. 为了解决上面的问题，产生了很多邮件访问协议，包括Post Office-Version 3(POP3)，Internet Access Protocal(IMAP)和HTTP
3. POP3是一种很简单的邮件访问协议，分为两种模式download-and-delete和download-and-keep。使用前者的模式，在一台机器上查询过邮件后无法在另一台机器上看到，使用后者的模式可以在多台机器上访问同一邮件。
4. IMAP邮件访问协议相比POP3更加复杂，增加了folder功能，我们可以在邮件服务器中创建相应的folder来管理邮件
5. 现如今，越来越多的邮件供应商使用HTTP来作为用户代理与邮件服务器之间的协议。发送方从客户代理(browser)发送邮件到服务器不再使用SMTP，而是使用HTTP；接收方使用HTTP协议从服务器拉取邮件到浏览器端，而不再使用POP3或者IMAP。但是，服务器与服务器之间的传输仍旧使用SMTP

DNS-The Internet’s Directory Service

Services Provided by DNS

1. 在计算机网络中，可以根据主机名或者IP地址来识别一个主机。对于人类来说，我们习惯使用主机名因为它便于记忆，但是路由器喜欢使用定长的，有着层次结构的IP地址。因此我们需要一种类似字典的服务，将我们人类喜欢的主机名翻译成IP地址，以进一步建立TCP连接。
2. DNS(domain name system)是一个由分层的DNS服务器实现的分布式数据库，DNS也是一个应用层协议，底端运输层使用UDP，默认端口是53
3. DNS是被其他应用层协议广泛使用的协议，当给我们的浏览器使用HTTP协议访问网站的时候，第一件事要做的就是使用DNS协议通过主机名获取IP地址。浏览器会提取我们想要访问的主机名，然后本机的DNS客户端向DNS服务器请求这个主机名的IP地址，收到响应后浏览器才能建立TCP连接。
4. DNS除了有进行主机名到IP地址的转换的功能，还有以下的功能：
   • 主机别名(host aliasing)：有些主机有着复杂的主机名，为了方便人们记忆，我们可以为这个复杂的主机名起多个别名。比如一台名为relay1.west-cost.enterprise.com的主机，可能有两个别名为enterprise.com和www.enterprise.com。这种情况下，我们把relay1.west-cost.enterprise.com称为规范主机名(canonical hostname)。注意，只有在有别名的情况下，对应的我们才有规范主机名这一说，加入一个主机名足够简单并且没有别名，比如www.google.com，那么也就不存在规范主机名。 DNS的一大作用就是可以通过别名，得到规范主机名和其IP地址
   • 邮件服务器别名(mail server aliasing)：与上面提到的主机别名一样，有些邮件服务器的主机名可能更为复杂，比如规范主机名可能是relay1.west-coast.hotmail.com，我们也可以为复杂的邮件服务器主机起别名，甚至一个公司的邮件服务器和web服务器可以使用相同的别名，这是通过MX记录实现了。
   • 负载分配(load distribution)：DNS也被用于某些复制服务器上，对于一些繁忙的站点，往往需要有多个复制的服务器运行在不同的端系统上，每个服务器都有着不同的IP地址。这些IP地址集合会与一个规范主机名相联系，当有客户请求这个规范主机名的时候，DNS服务器会返回所有这些IP的集合，但是在每次返回之前都会循环这些地址的次序。因为客户总是选择IP地址排在最前面的服务器发送HTTP请求，所以DNS就在这些相同的服务服务器之间实现了负载分配。

Overview of How DNS works

1. 我们可以把DNS看成一个分布式，有层次的数据库，没有一台DNS服务器拥有因特网上所有主机的映射。大致来说有三种类型的DNS服务器：根服务器(root DNS servers)，顶级域(Top-Level Domain, TLD)服务器和权威服务器(authoritative DNS servers)。当我们想要查询www.amazon.com的IP地址的时候，DNS客户端会先去根服务器上查找并返回com这一顶级域服务器的IP地址，随后DNS客户端去.com这一顶级域服务器查找并返回amazon.com这一权威服务器的IP地址，最后客户端从amazon.com这一权威服务器中找到www.amazon.com的IP地址。
2. 世界上有400多个根服务器，分布于世界各地。根服务器只负责提供顶级域服务器的IP地址。当我看书看到这里的时候，产生了一个疑问，明明使用dig +trace www.google.com的时候，只返回了13个根服务器，为什么书中要说有400多个根服务器呢？所以我尝试dig +trace a.root-servers.net，返回的结果是a.root-servers.net. 3600000 IN A 198.41.0.4。我在网络上搜索这个IP地址，地点位于堪萨斯州，隶属于VeriSign Infrastructure公司。这个时候我想，难道是因为我的本地DNS在美国，所以返回的是离我最近的A root根服务器的IP？所以我尝试把本地DNS切换成百度的DNS服务器，拿到的IP地址仍然是198.41.0.4。原因是世界上原本只有13个根服务器，至于为什么是13，有专门的文章介绍，其他的根服务器都是镜像服务器，但是所有相同的镜像服务器与其对应的根服务器都有相同的IP地址，这里使用了Anycast技术。这就是为什么我怎么查询A root根服务器的IP地址都不会变。https://segmentfault.com/a/1190000023696737
3. 顶级域服务器包括com，org，net，edu，gov以及国家的顶级域uk，cn，jp等。顶级域服务器负责提供权威服务器的IP地址
4. 权威服务器中可能存有我们想要查找的主机名的IP地址，也可能这个权威服务器没有，那么这时候它会返回一个下一级的权威服务器，直到找到我们需要的主机的IP地址。比如我们想要寻找toy.amazon.com的IP地址，可能在dns.amazon.com这一权威地址就存储了toy.amazon.com的IP地址，也可能dns.amazon.com告诉我们它这里，诶呦，我么应该去dns.toy.amazon.com这个权威服务器去寻找。
5. 除了上面提到的DNS服务器的层次结构，还有一种DNS服务器，并不隶属于前面的层次结构，但却十分重要，这就是本地DNS服务器，我们请求DNS的时候，不是直接去根服务器进行请求，而是去本地DNS服务器先进行请求。本地DNS服务器可以直接在电脑中设置，也就是说我可以设置本地DNS服务器为google提供的DNS服务器，也可以设置成baidu提供的，或者使用ISP提供的离我最近的DNS服务器，通常每人使用ISP提供的，因为速度最快。
6. DNS查询既可以是递归查询也可以是迭代查询，可以参考书中的图2.19和图2.20
7. DNS还有一个很重要的特性：DNS缓存。在一个请求链中，当某个DNS服务器接受一个DNS回答时，它能将结果存储在本地存储器中。这样的话，如果有一个相同的请求到达这个DNS服务器，直接返回结果。比如当我像本地DNS服务器请求Google.com的IP地址的时候，大概率已经被其缓存过了，所以根本不需要经过本地服务器->根服务器->TLD服务器->权威服务器这一条线。所以其实除了某些很冷门的顶级域，大部分的顶级域比如com的DNS服务器的IP地址都已经被缓存了，我们的请求根本不会经过根服务器。

DNS records and messages

1. 前面我们说了，DNS是一个分布式的数据库，存储在数据库中的数据叫做资源记录(resource records, RRs). 一条资源记录是一个四元组：(Name, Value, Type, TTL)。 TTL是一条资源记录的生存时间，它决定了什么时候这条记录会从缓存中被删除。Name和Value的含义取决于Type的值。
2. 如果Type=A，代表是Address record，那么Name就是一个主机名，Value是其对应的IP地址。(relay.bar.foo.com, 145.37.93.126, A)
3. 如果Type=NS，代表的是Name server record，那么Name是一个域，Value是一个知道如何获得该域中主机IP地址的权威服务器的主机名。(foo.com, dns.foo.com, NS)。所以NS记录是帮助我们一步一步在DNS查找链中前进的记录，比如在根服务器中，一定会存储(com, dns.com, NS)这样的记录，这样我们才知道如果我们下一步要去dns.com这个com域的TLD服务器找DNS。
4. 如果Type=CNAME，代表的是Canonical name record，那么Name是一个别名，Value是对应的规范主机名(真名)。(fake.liushiy.com, www.web.liushiy.com, CNAME)
5. 如果Type=MX，代表的是Mail exchange record，那么Name是一个别名，Value是对应的规范邮件主机名(真名)。(fake.liushiy.com, www.mail.liushiy.com, CNAME)。这里我们可以看到，我们可以为邮件服务器和web服务器起相同的别名，当搜索DNS的时候，如果需要的是邮件服务器的真名，那么DNS客户端会去请求MX记录，如果需要的是其他服务的服务器真名，那么DNS客户端会去请求CNAME记录。
6. 如果一台DNS服务器是用于某特定主机名的权威服务器，那么这个服务器中会有一条关于该主机名的A记录，这样客户端在到达这个DNS服务器的时候就可以通过主机名获取到IP地址了。当然大多数时候由于缓存的存在，即使某个服务器不是特定主机的权威服务器，也会存有缓存有相应的A记录。如果某个DNS服务器不是某个主机的权威服务器，那么它将存有一条NS记录，该记录给我们提供可能找到该主机DNS信息的权威服务器的主机名，这里可能有个疑问，也就是说只有一个A记录我们是不能继续往下进行链式搜索了，因为我们只知道主机名不知道IP地址，那么答案是这种服务器除了有一个NS记录外，也会存一个A记录，这个A记录的Name就是NS记录的Value。还是上面的例子，我们有个(com, dns.com, NS)这样一条NS记录，我们是没法去到dns.com这个TLD服务器的，所以还会有一条(dns.com, 123.123.123, A)的A记录。
7. DNS报文及它的内容见书中的图2.21DNS服务器和一个辅助权威DNS服务器，名字分别为dns1.network.com(212.212.212.1)和dns2.network.com(212.212.212.2)，域名注册机构会把这两个权威服务器的NS记录和A记录插入到TLD服务器中，同时我们还需要确保我们的域名的A记录插入到这两个权威服务器中。
8. 前面我们讨论的都是如何获取DNS的记录，那么如何在DNS数据库中插入记录呢？答案是有专业的域名注册登记机构，将域名输入DNS数据库。假设我们的某个域名(www.liushiy.com)有一个基本权威

Peer-to-Peer File Distribution

1. P2P比起client-server的优势在于client-server只有服务器在上传文件，其他的客户都是在下载，那么客户的上传速率就被浪费了，而P2P所有的用户都参与上传和下载。所以当分享同一个文件的时候，用户数量越多，P2P效果越好。具体的计算见书中。
2. P2P最有名的协议是BitTorrent，比较复杂，书中也只是简单提了一下。P2P这块比起前面几小节没那么重要。

Video Streaming and Content Distribution Networks

Content Distribution Networks

1. 对于请求流量很大的网站或者视频网站，CDN技术有很大的帮助。CDN的原理是把一个网站的内容拷贝到世界各地的镜像内容分发网站，当用于请求内容的时候，会自动去到最近的CDN服务器中获取内容，而不需要全部去到中心服务器中，这样可以减少中心服务器的流量。很多有大量客户的网站或者视频网站都会自己建立或者购买CDN服务。
2. CDN服务本质上是一种web cache，他不会直接储存中心网站的所有内容，而是当有用户请求的时候，他再去中心网站拉去请求，在返回给客户的同时在自己本地缓存，这样如果有其他客户请求相同的内容，就可以直接返回了。
3. 上面我们提到当客户请求内容的时候，会自动的去最近的CDN服务器请求，这是怎么办到的呢？答案是使用DNS技术，比如假设我们去Youtube请求一个视频，Youtube的权威服务器不会返回Youtube网站的IP地址，而是返回Youtube购买或自建的CDN网站的域名，比如a1105.somecdncompany.com。后面我们对于DNS的请求就进入了somecdncompany的私有DNS架构中了，它使用特定的算法返回给客户最近的CDK服务器的IP地址，于是客户就去到这个CDN服务器去请求内容了。

Wireshark DNS Lab

1. DNS Lab使用的查询DNS的命令式nslookup，但是nslookup不支持迭代查询，这一点上不如dig +trace好用

2. nslookup -type=NS www.tencent.com的意思是寻找www.tencent.com的权威服务器，测试的时候我用dig +trace找到了腾讯的权威服务器。第一个块的意思是我们在c.gtld-servers.net这个服务器上找到了tencent.com.的NS记录，指向了四个权威服务器；接着在ns1.qq.com这个服务器上找到了www.tencent.com.的NS记录，也指向了四个权威服务器。在实验的时候，我很傻的跑了一句nslookup -type=NS www.tencent.com ns-tel1.qq.com，结果是没有answer。www.tencent.com. 86400 IN NS ns-tel1.qq.com.的意思是www.tencent.com.的权威服务器是ns-tel1.qq.com.，我跑的那句命令的意思是去www.tencent.com的权威服务器找它的权威服务器，这怎么可能找得到呢？自己怎么可能找到的自己呢？

   tencent.com.		172800	IN	NS	ns1.qq.com.
   tencent.com.		172800	IN	NS	ns2.qq.com.
   tencent.com.		172800	IN	NS	ns3.qq.com.
   tencent.com.		172800	IN	NS	ns4.qq.com.
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20210824042516 20210817031516 39343 com. KAjDyjYoqq6PKGIFiVPSK63PL7G5kZs+/SibL2EvQnqc4CiS0vAuZ2LB p2cdbwFEH2Il3EUIzlH3AbXtlRzyZbpd7X4teLX1ZPX/f2gx6nwFK2A3 j+RzmROGkNAi/VOwvhv52We58iGCar+a54Yu+XfWu8PUi97228adtyhl E4sXQnx1rgyn5qzzTYg5B4yEMWKTCUK7tSo8RLFt/Wp+MA==
   VF2UKFM00JNRDJOAMAOL6M4S6MI030VN.com. 86400 IN NSEC3 1 1 0 - VF2UTHOP0RH8T5MV2F5D6VIBH626EP7Q  NS DS RRSIG
   VF2UKFM00JNRDJOAMAOL6M4S6MI030VN.com. 86400 IN RRSIG NSEC3 8 2 86400 20210824044708 20210817033708 39343 com. e6zgkDoZSwzs5S9EFGgPVDKgvHvGrPkud6Ro8Qs2pPUYlmGiE2q2wFEt vOXA1VYU3izMpiYyDoDYHOwolBPIHEibdG/cF632wKAOJM+LPAJYDt0v zwQOZZrYhJ40WOSP9P/BtDTL7rmO3H5YnXbNUzle1d8AhEslIhAqix0c AlUL/oag1yovBIKo9/FAa8NNjx+Ub36FE3FDcF8c2uQ1zw==
   ;; Received 996 bytes from 192.26.92.30#53(c.gtld-servers.net) in 1033 ms
   
   www.tencent.com.	86400	IN	NS	ns-cnc1.qq.com.
   www.tencent.com.	86400	IN	NS	ns-os1.qq.com.
   www.tencent.com.	86400	IN	NS	ns-cmn1.qq.com.
   www.tencent.com.	86400	IN	NS	ns-tel1.qq.com.
   ;; Received 398 bytes from 157.255.246.101#53(ns1.qq.com) in 301 ms

   shiyuliu@Shiyu-MacBookPro:~ $ nslookup -type=NS www.tencent.com ns-tel1.qq.com
   Server:		ns-tel1.qq.com
   Address:	123.151.66.83#53
   
   *** Can't find www.tencent.com: No answer

3. DNS案例分析：对www.tencent.com进行DNS分析，经过层层NS记录查找，在ns-cnc1.qq.com这个服务器找到www.tencent.com的化名www.tencent.com.cdn.dnsv1.com。随后对这个主机名进行新一轮的查找，经过层层NS记录查找，在d.dnspood.net这个服务器找到www.tencent.com.cdn.dnsv1.com的化名lffgjgyi.tweb.sched.ovscdns.com。最后对这个主机名进行层层查找，最后找到多条A记录，也就是腾讯服务器的真实IP地址。

   shiyuliu@Shiyu-MacBookPro:~ $ dig +trace www.tencent.com
   
   ; <<>> DiG 9.10.6 <<>> +trace www.tencent.com
   ;; global options: +cmd
   .			479895	IN	NS	b.root-servers.net.
   .			479895	IN	NS	c.root-servers.net.
   .			479895	IN	NS	d.root-servers.net.
   .			479895	IN	NS	e.root-servers.net.
   .			479895	IN	NS	f.root-servers.net.
   .			479895	IN	NS	g.root-servers.net.
   .			479895	IN	NS	h.root-servers.net.
   .			479895	IN	NS	a.root-servers.net.
   .			479895	IN	NS	i.root-servers.net.
   .			479895	IN	NS	j.root-servers.net.
   .			479895	IN	NS	k.root-servers.net.
   .			479895	IN	NS	l.root-servers.net.
   .			479895	IN	NS	m.root-servers.net.
   .			479895	IN	RRSIG	NS 8 0 518400 20210901050000 20210819040000 26838 . CO4nAv6FI9pIG3VzDOEtvle2R1OqByvjG5H1w1J47bTlf5aisb49aPfH Fy9IgBL1ffeRC9J7L1k3cf/78zDpTKhgdwN2oE6hRFifODgba7FPsU2u 3W2Bk0NJE6kapJDjX6HTnUnFmpMhHEHR2zPqIa9IgSgIrrJL7TdL0a+8 JFSafxfKGHmGXRjIglLkImcoEk+D4DETIhhWNjyOaQ7aFo3iioeijk/M oVE+9v/hPrr4djB3bfIGfI4TDAdUWegCILe0LLXXG20RTpMtqYNL5d1R 1rzPWMIlnLD6HwBOQTsidSa86MnWIJOv6lpXfVTeDRF639ThkooW978z BFzEQQ==
   ;; Received 1097 bytes from 192.168.0.1#53(192.168.0.1) in 14 ms
   
   com.			172800	IN	NS	a.gtld-servers.net.
   com.			172800	IN	NS	b.gtld-servers.net.
   com.			172800	IN	NS	c.gtld-servers.net.
   com.			172800	IN	NS	d.gtld-servers.net.
   com.			172800	IN	NS	e.gtld-servers.net.
   com.			172800	IN	NS	f.gtld-servers.net.
   com.			172800	IN	NS	g.gtld-servers.net.
   com.			172800	IN	NS	h.gtld-servers.net.
   com.			172800	IN	NS	i.gtld-servers.net.
   com.			172800	IN	NS	j.gtld-servers.net.
   com.			172800	IN	NS	k.gtld-servers.net.
   com.			172800	IN	NS	l.gtld-servers.net.
   com.			172800	IN	NS	m.gtld-servers.net.
   com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
   com.			86400	IN	RRSIG	DS 8 1 86400 20210901170000 20210819160000 26838 . LHS6RGFU2XE72HDMmEXCGuWJCaMO36pnSrAQ4ziSXN+7Jm+FZu0+CE9t rCq5oKF5DqGTAmq6lA4vo2kPcZy8ywQy4Nq1cGUwXlHvZk+4MZsqffJg mDZMrdNBuYG+EcN8v+oa9DXMSwOYMnesilFHhhUpTLRPet/WeQzVt1Gg 5APdWPwd6LkNNA+0ir3BXpmg0gFsPNNdNKzq0x7tHA8mMt57gNb+iFP9 9zcVhQ0FnPfdUR2hKG9N7YKcWgxHskshFGnfQ0JyDfFwwNOnkBJGBh++ 52iwqEoqsIsJwn/Mov0qCgImX6jhFB4eGVYh2bStWQfZmpeqzxsPtflE EoXiWg==
   ;; Received 1175 bytes from 199.9.14.201#53(b.root-servers.net) in 39 ms
   
   tencent.com.		172800	IN	NS	ns1.qq.com.
   tencent.com.		172800	IN	NS	ns2.qq.com.
   tencent.com.		172800	IN	NS	ns3.qq.com.
   tencent.com.		172800	IN	NS	ns4.qq.com.
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20210824042516 20210817031516 39343 com. KAjDyjYoqq6PKGIFiVPSK63PL7G5kZs+/SibL2EvQnqc4CiS0vAuZ2LB p2cdbwFEH2Il3EUIzlH3AbXtlRzyZbpd7X4teLX1ZPX/f2gx6nwFK2A3 j+RzmROGkNAi/VOwvhv52We58iGCar+a54Yu+XfWu8PUi97228adtyhl E4sXQnx1rgyn5qzzTYg5B4yEMWKTCUK7tSo8RLFt/Wp+MA==
   VF2UKFM00JNRDJOAMAOL6M4S6MI030VN.com. 86400 IN NSEC3 1 1 0 - VF2UTHOP0RH8T5MV2F5D6VIBH626EP7Q  NS DS RRSIG
   VF2UKFM00JNRDJOAMAOL6M4S6MI030VN.com. 86400 IN RRSIG NSEC3 8 2 86400 20210824044708 20210817033708 39343 com. e6zgkDoZSwzs5S9EFGgPVDKgvHvGrPkud6Ro8Qs2pPUYlmGiE2q2wFEt vOXA1VYU3izMpiYyDoDYHOwolBPIHEibdG/cF632wKAOJM+LPAJYDt0v zwQOZZrYhJ40WOSP9P/BtDTL7rmO3H5YnXbNUzle1d8AhEslIhAqix0c AlUL/oag1yovBIKo9/FAa8NNjx+Ub36FE3FDcF8c2uQ1zw==
   ;; Received 996 bytes from 192.26.92.30#53(c.gtld-servers.net) in 1033 ms
   
   www.tencent.com.	86400	IN	NS	ns-cnc1.qq.com.
   www.tencent.com.	86400	IN	NS	ns-os1.qq.com.
   www.tencent.com.	86400	IN	NS	ns-cmn1.qq.com.
   www.tencent.com.	86400	IN	NS	ns-tel1.qq.com.
   ;; Received 398 bytes from 157.255.246.101#53(ns1.qq.com) in 301 ms
   
   www.tencent.com.	60	IN	CNAME	www.tencent.com.cdn.dnsv1.com.
   ;; Received 84 bytes from 116.128.153.20#53(ns-cnc1.qq.com) in 1324 ms

   shiyuliu@Shiyu-MacBookPro:~ $ dig +trace www.tencent.com.cdn.dnsv1.com
   
   ; <<>> DiG 9.10.6 <<>> +trace www.tencent.com.cdn.dnsv1.com
   ;; global options: +cmd
   .			480233	IN	NS	d.root-servers.net.
   .			480233	IN	NS	e.root-servers.net.
   .			480233	IN	NS	f.root-servers.net.
   .			480233	IN	NS	g.root-servers.net.
   .			480233	IN	NS	h.root-servers.net.
   .			480233	IN	NS	a.root-servers.net.
   .			480233	IN	NS	i.root-servers.net.
   .			480233	IN	NS	j.root-servers.net.
   .			480233	IN	NS	k.root-servers.net.
   .			480233	IN	NS	l.root-servers.net.
   .			480233	IN	NS	m.root-servers.net.
   .			480233	IN	NS	b.root-servers.net.
   .			480233	IN	NS	c.root-servers.net.
   .			480233	IN	RRSIG	NS 8 0 518400 20210901050000 20210819040000 26838 . CO4nAv6FI9pIG3VzDOEtvle2R1OqByvjG5H1w1J47bTlf5aisb49aPfH Fy9IgBL1ffeRC9J7L1k3cf/78zDpTKhgdwN2oE6hRFifODgba7FPsU2u 3W2Bk0NJE6kapJDjX6HTnUnFmpMhHEHR2zPqIa9IgSgIrrJL7TdL0a+8 JFSafxfKGHmGXRjIglLkImcoEk+D4DETIhhWNjyOaQ7aFo3iioeijk/M oVE+9v/hPrr4djB3bfIGfI4TDAdUWegCILe0LLXXG20RTpMtqYNL5d1R 1rzPWMIlnLD6HwBOQTsidSa86MnWIJOv6lpXfVTeDRF639ThkooW978z BFzEQQ==
   ;; Received 1081 bytes from 192.168.0.1#53(192.168.0.1) in 3966 ms
   
   com.			172800	IN	NS	a.gtld-servers.net.
   com.			172800	IN	NS	b.gtld-servers.net.
   com.			172800	IN	NS	c.gtld-servers.net.
   com.			172800	IN	NS	d.gtld-servers.net.
   com.			172800	IN	NS	e.gtld-servers.net.
   com.			172800	IN	NS	f.gtld-servers.net.
   com.			172800	IN	NS	g.gtld-servers.net.
   com.			172800	IN	NS	h.gtld-servers.net.
   com.			172800	IN	NS	i.gtld-servers.net.
   com.			172800	IN	NS	j.gtld-servers.net.
   com.			172800	IN	NS	k.gtld-servers.net.
   com.			172800	IN	NS	l.gtld-servers.net.
   com.			172800	IN	NS	m.gtld-servers.net.
   com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
   com.			86400	IN	RRSIG	DS 8 1 86400 20210901170000 20210819160000 26838 . LHS6RGFU2XE72HDMmEXCGuWJCaMO36pnSrAQ4ziSXN+7Jm+FZu0+CE9t rCq5oKF5DqGTAmq6lA4vo2kPcZy8ywQy4Nq1cGUwXlHvZk+4MZsqffJg mDZMrdNBuYG+EcN8v+oa9DXMSwOYMnesilFHhhUpTLRPet/WeQzVt1Gg 5APdWPwd6LkNNA+0ir3BXpmg0gFsPNNdNKzq0x7tHA8mMt57gNb+iFP9 9zcVhQ0FnPfdUR2hKG9N7YKcWgxHskshFGnfQ0JyDfFwwNOnkBJGBh++ 52iwqEoqsIsJwn/Mov0qCgImX6jhFB4eGVYh2bStWQfZmpeqzxsPtflE EoXiWg==
   ;; Received 1189 bytes from 199.7.91.13#53(d.root-servers.net) in 1024 ms
   
   dnsv1.com.		172800	IN	NS	c.dnspood.net.
   dnsv1.com.		172800	IN	NS	d.dnspood.net.
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20210824042516 20210817031516 39343 com. KAjDyjYoqq6PKGIFiVPSK63PL7G5kZs+/SibL2EvQnqc4CiS0vAuZ2LB p2cdbwFEH2Il3EUIzlH3AbXtlRzyZbpd7X4teLX1ZPX/f2gx6nwFK2A3 j+RzmROGkNAi/VOwvhv52We58iGCar+a54Yu+XfWu8PUi97228adtyhl E4sXQnx1rgyn5qzzTYg5B4yEMWKTCUK7tSo8RLFt/Wp+MA==
   SQ33O0H4MV9I02VGSVRC1STI0J9S6AQL.com. 86400 IN NSEC3 1 1 0 - SQ348AROC5M6FCS12QPU0C1MPDTFTDM9  NS DS RRSIG
   SQ33O0H4MV9I02VGSVRC1STI0J9S6AQL.com. 86400 IN RRSIG NSEC3 8 2 86400 20210825041849 20210818030849 39343 com. Kj2RAJxb6DZfRiFTPMsH6Q45X6s9pgFlJkxO2NsJx+Gi/RBvRj6PDZ05 j+u6pqAU1MnMWyerJzD3IND6z9qm66uM+MHazukEOqPDctJrBgVyrQqe YT0QD0FpsojGcUAB6pGYxDFY9I5gLOWlYaDwNhyj9LNgurFMsDV1KP06 Y+HcXwJPoMkDrcPS2kFdupPMGmHEI/1m3Nz7bKc7pgo6CQ==
   ;; Received 650 bytes from 192.54.112.30#53(h.gtld-servers.net) in 54 ms
   
   www.tencent.com.cdn.dnsv1.com. 600 IN	CNAME	lffgjgyi.tweb.sched.ovscdns.com.
   dnsv1.com.		86400	IN	NS	ns4.dnsv5.com.
   dnsv1.com.		86400	IN	NS	ns3.dnsv5.com.
   ;; Received 157 bytes from 52.66.148.160#53(d.dnspood.net) in 1155 ms

   shiyuliu@Shiyu-MacBookPro:~ $ dig +trace lffgjgyi.tweb.sched.ovscdns.com
   
   ; <<>> DiG 9.10.6 <<>> +trace lffgjgyi.tweb.sched.ovscdns.com
   ;; global options: +cmd
   .			478969	IN	NS	d.root-servers.net.
   .			478969	IN	NS	e.root-servers.net.
   .			478969	IN	NS	f.root-servers.net.
   .			478969	IN	NS	g.root-servers.net.
   .			478969	IN	NS	h.root-servers.net.
   .			478969	IN	NS	a.root-servers.net.
   .			478969	IN	NS	i.root-servers.net.
   .			478969	IN	NS	j.root-servers.net.
   .			478969	IN	NS	k.root-servers.net.
   .			478969	IN	NS	l.root-servers.net.
   .			478969	IN	NS	m.root-servers.net.
   .			478969	IN	NS	b.root-servers.net.
   .			478969	IN	NS	c.root-servers.net.
   .			478969	IN	RRSIG	NS 8 0 518400 20210901050000 20210819040000 26838 . CO4nAv6FI9pIG3VzDOEtvle2R1OqByvjG5H1w1J47bTlf5aisb49aPfH Fy9IgBL1ffeRC9J7L1k3cf/78zDpTKhgdwN2oE6hRFifODgba7FPsU2u 3W2Bk0NJE6kapJDjX6HTnUnFmpMhHEHR2zPqIa9IgSgIrrJL7TdL0a+8 JFSafxfKGHmGXRjIglLkImcoEk+D4DETIhhWNjyOaQ7aFo3iioeijk/M oVE+9v/hPrr4djB3bfIGfI4TDAdUWegCILe0LLXXG20RTpMtqYNL5d1R 1rzPWMIlnLD6HwBOQTsidSa86MnWIJOv6lpXfVTeDRF639ThkooW978z BFzEQQ==
   ;; Received 1097 bytes from 192.168.0.1#53(192.168.0.1) in 3492 ms
   
   com.			172800	IN	NS	a.gtld-servers.net.
   com.			172800	IN	NS	b.gtld-servers.net.
   com.			172800	IN	NS	c.gtld-servers.net.
   com.			172800	IN	NS	d.gtld-servers.net.
   com.			172800	IN	NS	e.gtld-servers.net.
   com.			172800	IN	NS	f.gtld-servers.net.
   com.			172800	IN	NS	g.gtld-servers.net.
   com.			172800	IN	NS	h.gtld-servers.net.
   com.			172800	IN	NS	i.gtld-servers.net.
   com.			172800	IN	NS	j.gtld-servers.net.
   com.			172800	IN	NS	k.gtld-servers.net.
   com.			172800	IN	NS	l.gtld-servers.net.
   com.			172800	IN	NS	m.gtld-servers.net.
   com.			86400	IN	DS	30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
   com.			86400	IN	RRSIG	DS 8 1 86400 20210901170000 20210819160000 26838 . LHS6RGFU2XE72HDMmEXCGuWJCaMO36pnSrAQ4ziSXN+7Jm+FZu0+CE9t rCq5oKF5DqGTAmq6lA4vo2kPcZy8ywQy4Nq1cGUwXlHvZk+4MZsqffJg mDZMrdNBuYG+EcN8v+oa9DXMSwOYMnesilFHhhUpTLRPet/WeQzVt1Gg 5APdWPwd6LkNNA+0ir3BXpmg0gFsPNNdNKzq0x7tHA8mMt57gNb+iFP9 9zcVhQ0FnPfdUR2hKG9N7YKcWgxHskshFGnfQ0JyDfFwwNOnkBJGBh++ 52iwqEoqsIsJwn/Mov0qCgImX6jhFB4eGVYh2bStWQfZmpeqzxsPtflE EoXiWg==
   ;; Received 1191 bytes from 199.7.83.42#53(l.root-servers.net) in 1023 ms
   
   ovscdns.com.		172800	IN	NS	ns1.ovscdns.com.
   ovscdns.com.		172800	IN	NS	ns2.ovscdns.com.
   ovscdns.com.		172800	IN	NS	ns3.ovscdns.com.
   ovscdns.com.		172800	IN	NS	ns4.ovscdns.com.
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
   CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20210824042516 20210817031516 39343 com. KAjDyjYoqq6PKGIFiVPSK63PL7G5kZs+/SibL2EvQnqc4CiS0vAuZ2LB p2cdbwFEH2Il3EUIzlH3AbXtlRzyZbpd7X4teLX1ZPX/f2gx6nwFK2A3 j+RzmROGkNAi/VOwvhv52We58iGCar+a54Yu+XfWu8PUi97228adtyhl E4sXQnx1rgyn5qzzTYg5B4yEMWKTCUK7tSo8RLFt/Wp+MA==
   RVDEHMBPSB0379D5051JJP8Q8UU7FPEA.com. 86400 IN NSEC3 1 1 0 - RVDF6S6QPNNO8GHLHISI3D8FBAERQVJ1  NS DS RRSIG
   RVDEHMBPSB0379D5051JJP8Q8UU7FPEA.com. 86400 IN RRSIG NSEC3 8 2 86400 20210825155810 20210818144810 39343 com. YtSvi1oy1qGohuUdpmvYJwSdd4bKlB2+FeI1gqRY2Pqk9jLT+OMkpK6a UOljZEhReVGj+QLmqfZZg+410Zb0RNONLmFLUXBIsKHzIHpSaxlddjIb nqm/pbf0pjxb7IFi9iNV9BiovdBXjHBvASgYS5l+OgQGE6/63I1jyJK/ 930MqPgdcMpml/uW3rkipEVMkQrOQFk3K7FbGqvR7W6Jlw==
   ;; Received 777 bytes from 192.26.92.30#53(c.gtld-servers.net) in 75 ms
   
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.44
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.99
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.146.90
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.84
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.72
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.30
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.146.99
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.146.98
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.146.86
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.29
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.78
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.43
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.77
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.149.16
   lffgjgyi.tweb.sched.ovscdns.com. 60 IN	A	211.152.148.87
   ;; Received 300 bytes from 203.205.194.114#53(ns2.ovscdns.com) in 1175 ms

Transport Layer

Introduction and Transport-Layer Services

1. 传输层协议为应用层进程提供逻辑通信。逻辑通信的意思是从应用的角度来看，主机间的进程似乎是直接连接在一起的，但实际上主机是通过很多路由器和通信链路连接在一起的，两台主机可能在地球的两端，他们只是从逻辑上是直接连接的，物理上并不是。
2. 网络层与传输层的关系的一个类比：假设在东西海岸各有一个房子，A房子里有144个小孩，B房子里有这144个小孩的表哥，小孩和表哥之间每周都会互相写信。在每个房子，都有一个小孩负责收发信件(Ann在房子A，Bill在房子B)，每周Ann都会从所有的小孩那里收集新建，并且把信件投递给邮政服务，而另一端的Bill在收到这些信件后，会挨个分给每个小孩。在这个例子中，邮政服务提供了物理连接，它不负责为每个孩子之间提供连接，他只负责为两个房子之间提供连接，Ann和Bill提供了逻辑连接，因为它们负责每周的收发邮件。在孩子们的视角里，Ann和Bill就是他们的邮件系统，他们不需要知道后面发生了什么，只需要把信件发给Ann或者Bill就好了。应用消息=信件，进程=小孩，端系统=房子，传输层协议=Ann and Bill，网络层协议=邮政系统。
3. Ann和Bill只在两个房子里工作，他们不负责邮政系统的分拣邮件以及运输邮件，相同的，运输层协议只运作在两个终端，具体消息是如何在网络核心中传递的，运输层并不关心。
4. 如果某一天Ann和Bill放假了，换了一对新人Susan和Harvey来接管邮件分发业务，这里我们就可以理解为运输层可以有多个新协议(TCP和UDP)。
5. Ann和Bill所能提供的服务是由邮政服务所限制的，比如如果邮政服务不能提供最大投递时间，那么Ann和Bill也不能可能保证邮件的最大头投递延迟，相同的，如果传输层的服务也被网络层所限制，如果网络层不能提供带宽和延迟保障，俺么运输层是无论如何也提供不了的。但是运输层可以提供某些网络层不提供的服务，比如可靠运输。
6. 所以综上看来，传输层的最大作用是将网络中端到端的运输扩展为进程到进程的运输，端到端的运输由网络层负责，端到进程的运输由运输层负责，正因如此，运输层一个很重要的功能就是多路分解(transporter-layer multiplexing)和多路复用(transporter-layer demultiplexing)。同时运输层还提供一些网络层不具备的功能，比如拥塞控制和可靠运输。

Multiplexing and Demultiplexing

1. 一台主机上会运行多个进程(比如同时看网页，发邮件，传文件)，但是传到这台主机的报文段都是统一从网络层获得的，那么运输层把相应的报文段发到对应的进程中(通过有唯一标识符的套接字，也就是端口号)，这就是多路分解。当从这些进程的套接字收集报文段并统一发送出去，这就是多路复用。
2. 从上可知，运输层的多路分解和多路复用最重要的就是套接字的唯一标识符，也就是端口号，有了这个，运输层才知道把相应的报文发送到那个应用中去使用。所以传输层报文段长下面这个样子：
   32位
   Source port number | Destination port number
   Other header fields
   Application data(message)
   在传输层的报文段中最开始的就是源端口号和目的地端口号，各占16位(0-65535)，其中0-1023是一些周知端口号(well-known port numbers)。
3. UDP的多路复用与多路分解根据二元组：(Source port number, Destination Port Number)。接收端接收到报文段后根据Destination Port Number，把解析出来的应用层报文发送到对应的套接字中。
4. 由于UDP的多路复用在解析的时候其实只是根据Destination Port Number，所以如果两个不同IP地址的主机，发送相同的信息到同一个IP地址和端口号的主机，那么他们会进入同一个套接字，也就进入了同一个进程。那么Source Port Number用在哪里呢？答案是用在返回信息的时候，根据上面的二元组，返回信息的时候就变成了(Destination port number, Source port number)，也就是源变成了目的地，目的地变成了源。
5. TCP的多路复用与多路分解根据四元组：(Source IP address, Source port number, destination IP address, destination port number)。TCP服务器端有一个专门的套接字1用来等待TCP连接，并根据四元组的值，创建一个新的套接字2来处理后续的TCP报文段，如果后续再有有相同四元组的报文段到达，这个专门的套接字1根据四元组把这个报文段发送到套接字2处。所以如果四元组有任一个值不一样，都会进入不同的套接字中。
6. 值得一提的是，现代服务器中，套接字与进程往往不是一对一的了，而是使用一个线程来开启一个套接字并用于建立TCP连接。

Connectionless Transport: UDP

1. UDP报文段结构如下，Lengh记录了UDP报文段的长度，Checksum用于进行差错校验

   16位               | 16位
   Source Port Number | Destination Port Number
   Length             | Checksum
   Application data(message)

2. UDP除了提供多路分解与多路复用功能外，只提供最简单的差错校验。很多链路层协议提供差错校验，那么为什么UDP还需要提供差错校验呢：1.并不是所有链路层协议都提供差错校验 2.即使链路层没有发生问题，网络层也可能出现数据传输问题(比如在路由器的内存中出现问题)。UDP的差错校验是把除了Checksum外所有的16位数据进行加和(加和的时候如果有溢出，需要补到最后一位去)，然后求出反码得到的。那么当接收端拿到UDP报文段后，把所有的16位数据进行加和，如果结果不是111111111111111，那么代表传输过程中出现了错误。

Principles of Reliable Data Transfer

1. rdt1.0是一个底层不会有任何差错的协议，由于底层不会有任何差错，所以我们的receiver不需要回复任何确认信息给sender端。
2. rdt2.0协议考虑了底层传输遇到比特位错误的情况，也就是某个比特位从0变成1或者从1变成0的情况。为了解决这一问题，rdt2.0引入了三种能力：1. 差错检测(error detection)，也就是使用类似UDP的checksum方法对接收到的报文进行差错检测 2. Receiver feedback，也就是receiver需要返回给sender一个信号告诉它上次的传输成功还是失败，rdt2.0我们使用ACK和NAK两种acknowledgement 3. Retransmission，也就是当sender接收到receiver端传来的错误信息后，会进行原信息的再发送。
3. rdt2.0只考虑了发送的报文会遇到比特位错误的情况，但其实返回的ACK或者NAK也可能遇到比特位错误，解决的方法还是在ACK和NAK中也加入差错检测，这样sender端在收到ACK或者NAK的时候就知道是否发生了比特位错误，如果发生了比特位错误，就直接进行原信息的重发送。但这时引出了另一个问题：receiver端不清楚我们重发送的信息到底是一个新信息还是一个重发送的老信息，它也就无法确定是处理这个新信息还是忽略这个老信息。那么解决办法就是引入序列号(sequence number)，receiver端通过检查序列号就知道发送来的信息是一个新信息还是一个重发送的老信息。这也就是rdt2.1
4. rdt2.2删掉了NAK，只使用ACK，原理是不管receiver端收到的是out of order的message还是corrupted的message，receiver都只是返回上次成功接收的message的ACK。
5. 前面我们的协议都只考虑了比特位错误的情况，但没有考虑数据包在网络中可能丢失的情况，rdt3.0在此基础上增加了超时重传功能。
6. rdt协议有一个致命的缺陷就是他是一个stop and wait protocal，也就是说当sender端发送完一个message之后，会等待这个message的ACK返回，这样的效率太低且网络的throughput很低，解决办法是使用pipelined reliable data transfer protocols，主要有GBN和SR两种。
7. Go-Back-N(GBN)是一种滑动窗口协议，同一时间能够发送的message的数量由窗口的大小决定，具体窗口的定义见书中图3.19。GBN只有一个timer在进行计时，统计的是base处的message的时间，base处是窗口中第一个发出去但还没有收到ACK的message，当timeout的时候，所有base到nextseqnum-1的message都会被重新发送，这也是他被叫做Go-Back-N协议的原因。GBN协议的接收端没有窗口(也就是没有缓存)，所以如果到达的message不是我们需要的那个expectedseqnum，接收端就会扔掉它。GBN使用了cumulative acknowledgement，也就是假设n和n+1号message都被receiver端成功接收并处理了，但是返回的时候，n号message的ACK意外丢失了，sender端只收到了n+1号message的ACK，这个时候sender也会认为n和n+1号message已经被receiver端成功处理了，随即进行窗口的移动。在pipelined rdt协议中使用cumulative acknowledgement是很自然的做法。
8. GBN协议的一个很大的问题就是一旦接收端期待的message的接收遇到问题，即使后面的message都接收成功，也会导致所有messages的重传，这会导致大量的带宽被重传占用。为了解决这个问题，另一种协议Selective Repeat(SR)被引入，SR的基本思想就是为了避免过多的重传，在receiver端也设立一个窗口(也就是缓存)，当有乱序的message到达receiver端的时候，SR并不会将它们扔掉，而是缓存在窗口中，并且返回对应的ACK，同时sender端也不是只有一个计时器，而是对于每一个发送出去的message都有一个对应的计时器，如果在规定时间内没有接收到相应的ACK，就会触发超时重传机制。当sender端send_base处的message成功的接收到ACK时，sender端的窗口会移动到有最小sequence num的还未被ACK的message处；当receiver端的recv_base处的message被成功的接收到时，receiver端的窗口会移动到有最小sequence number的还没接收到message的位置。SR没有使用cumulative acknowledgement；同时SR的发送窗口与接收窗口并不一定同步对应(接收端窗口可能比发送端窗口先滑动，因为发送端窗口还没有收到ACK)；SR的窗口大小必须小于或等于sequence num的一半，否则会出现接收端窗口无法判断收到的message是重传还是新数据的问题。
9. 由上面的分析以及书中的示例图可知，GBN的窗口是连续的，所以实现的时候其实只需要两个指针(base, nextseqnum)即可；SR的窗口是不连续的(ACK之中夹杂着还没有ACK的)，所以只用指针是实现不了的，我猜底层是一个类似数组的东西在进行维护。

Connection-Oriented Transport: TCP

TCP Segment定义

1. TCP segment中数据的最大长度(maximum segment size, MSS)是由最大传输单元(maximum transamission)决定的，在以太网等链路层协议中，MTU的值一般为1500 bytes，那么减去IP协议的header(20字节)和TCP协议的header(20字节)，我们可以得出TCP segment中数据的最大长度一般为1460字节
2. TCP segment定义如下：

   												32 bits(4 bytes)
   Source port number                                 |Destination port number
   										Sequence number
   										Acknowledgment number
   Header lengh|Unused|CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|Receive window
   Internet checksum                                  |Urgent data pointer
   												Options
   												Data

   • 32位的Sequence number和32位的Acknowledgment number用于实现可靠数据传输
   • 16位的receive window用于流程控制中返回receiver window的大小
   • 4位的header length说明了TCP header的长度，一般来说TCP header的长度都是20字节，但是由于有options的存在，TCP header的长度可能大于20字节
   • options部分用于：1. sender和receiver沟通MSS的大小 2.sender和receiver沟通window scaling factor 3.定义timestamp option
   • flag部分定义了TCP使用的标志位：1.ACK标志位用于表示这个TCP segment中包含了一个ACK，也就是Acknowledgment number，其实在TCP通信的时候，只有第一个发起连接的SYN信号的segment中的ACK是0，其他所有的segment的ACK一定为1(因为TCP就是通过seq和ack来实现pipelined rdt，通过这两个值知道数据传输的情况，比如数据是否丢失，数据是否被接收到，这个在上一章已经说明了) 2.RST, SYN, FIN用于TCP的连接与断开 3.CWR, ECE用于拥塞控制 4.PSH代表收到的数据要立刻传递到上一层 5.URG指的是紧急数据
   • Urgent data pointer指明了紧急数据存放的位置

TCP数据传输

1. TCP传输的sequence number其实是字节流，而不是像我们前面介绍所说的传递的segment的序号。一个segment的sequence number其实是这个segment的第一个字节在字节流中的序号。
2. TCP的acknowledge number指的是作为接收者，期待对方传来的下一个sequence number。也就是当我们传回一个n的acknowledge number的时候，我们的意思是“嘿，我承认我收到了n-1 sequence number前所有的数据，下一次请从n号sequence number开始发”。因此，接收端发送的acknowledge number = 接收到收到的sequence number + 收到的数据长度，比如A发给B一条信息[seq = 100, Length = 200]，那么B返回的信息将是[ack = 300]；值得一提的是有些TCP segment的数据长度为0，比如SYN和FIN信号，这种情况下接收端发送的acknowledge number = 接收到收到的sequence number + 1。
3. TCP使用了cumulative acknowledgments，假设A向B发送了三个segment：第一个segment包含字节号0-535，第二个segment包含字节号536-899，第三个segment包含字节号900-100，但是由于网络原因第二个字节未被B收到，那么此时B返回的acknowledgement number会是536，也就是TCP返回的acknowledgement number是字节流中第一个缺失的字节。
4. TCP的initial sequence number不是固定的，而是在三次握手阶段选定的随机值，三次握手的一个主要作用就是选定并互相确认ISN
5. RFC中定义了很多上面这些细节，但是对于TCP的具体实现其实是没有定义的，所以本质上来说我们可以用GBN或者SR或者其他rdt协议实现TCP(早期TCP其实甚至是由stop-and-wait实现的)。现代操作系统上实现的TCP协议大致与GBN类似：1.都使用cumulative acknowledgments 2.sender端有一个滑动窗口 3.只使用一个timer，这个timer作用于有着最小sequence number的已经发送但还未被ACK的segment上。 但是有两点与GBN不同：1.TCP协议在receiver端也有一个滑动窗口(缓存)，用于接收out of order segment，这点与GBN直接扔掉out of order segment是不同的 2.当唯一的timer到时间后，TCP协议只会重发这个被计时的segment，而不是像GBN一样把后面的也都发了。 所以TCP可以看做GBN和SR的混合实现。
6. TCP中timeout的时间根据RTT进行计算，总结见书和这里：https://coolshell.cn/articles/11609.html
7. 前面提过，TCP的重传只作用于当前序列号最小的未被ACK的segment，并且重传的第一个timeout是由RTT计算的，但重传以后后面的timeout时间不再根据RTT计算，而是不断倍增，假设第一个timeout时间根据RTT计算出来是0.75，那么下一个timeout时间就会是1.5，3， 以此类推。
8. TCP还有一个特别的重传机制：fast retransmit，fast retransmit不是根据timeou时间进行重传，而是当我们收到同一个segment的三条相同ACK，那么很大可能是这条segment丢失了，但由于后面的segment被正常接收了，所以根据cumulative acknowledgement，不断返回least missing sequence number，这个时候TCP会直接进行重传，而不是继续等待timeout。

TCP流程控制与滑动窗口

1. TCP sender端的滑动窗口与GBN相同，见图：https://github.com/ShiyuLiuColumbia/diagram/blob/main/Sliding%20window%20at%20TCP%20sender%20side.png. 窗口的大小N是由receive端传来的receive window决定的。
2. TCP receiver端的滑动窗口：https://github.com/ShiyuLiuColumbia/diagram/blob/main/Sliding%20window%20at%20TCP%20receiver%20side.png
3. 所以TCP流程控制的本质是一项速度匹配机制：发送端发送字节流的速度需要与接收端应用读取字节流的速度匹配。`Receive window(这是sender端将要收到的滑窗的N，由receive端提供的) = Receive buffer(这其实是receive端滑窗的N)-[LastByteRcvd - LastByteRead]
4. 流控这种由receiver端控制sender的方式也会造成一些问题。1.Zero Window： 假设receiver端发给sender端的一个ACK segment的receive window是0。并且后面恰好receiver端没有新的数据发送给sender端，就会出现sender端停止发送数据的情况，因为sender端认为receiver端没有可以接受数据的位置了，即使后面receiver端某些buffer被空了出来，sender端也永远不会知道了。解决办法是sender后面还会间隔一段时间发送空数据的segment到receiver，这样receiver的ACK segment可能会包含新的receive window的值。https://coolshell.cn/articles/11609.html#Zero_Window 2.Window shrinking，也就是receive window的值(比如20)发送出去后，receiver端的buffer减少了，使得receiver端没有足够的buffer接收数据了：http://www.tcpipguide.com/free/t_TCPWindowManagementIssues.htm 3. Silly Window Syndrome: 如果我们的接收方太忙了，来不及取走Receive Windows里的数据，那么，就会导致发送方越来越小。到最后，如果接收方腾出几个字节并告诉发送方现在有几个字节的window，而我们的发送方会义无反顾地发送这几个字节。要知道，我们的TCP+IP头有40个字节，为了几个字节，要达上这么大的开销，这太不经济了。http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm

TCP三次握手与四次挥手

1. TCP三次握手与四次挥手的过程以及状态机的变化在书中及各个博客有很详细的描述，这里就不赘述了 https://coolshell.cn/articles/11564.html#TCP%E7%9A%84%E7%8A%B6%E6%80%81%E6%9C%BA
2. TCP为什么要进行三次握手？TCP的三次挥手本质上是为了在不可靠的信道上可靠地传输信息，而这一需求最少需要进行三次握手，当然我们进行4次，5次或者更多次都是可以的，但是最少需要三次。TCP三次握手在干什么呢？最重要的就是sender端和receiver端进行沟通并交换彼此初始化信息，其中最重要的一个信息就是ISN。试想如果sender和receiver不交换彼此初始化信息就开始进行TCP传输，那岂不是乱了套，任何主机间直接就能进行通信了。
3. TCP为什么是三次握手？两次或者四次不行吗？https://www.zhihu.com/question/24853633/answer/115173386 https://www.zhihu.com/question/24853633/answer/573627478
   其实三次挥手的原理非常非常简单，就是sender端发送它的初始化信息(ISN，window)，receiver端ACK，然后receiver端也发送它的初始化信息(ISN，window)，sender端ACK。其中receiver端ACK和receiver端也发送它的初始化信息这两个message可以在一条segment中发送，所以就变成了三次握手。
4. TCP为什么是四次挥手？断开连接的时候，A先告诉B我要断开连接(发送FIN)，B发送ACK，随后B告诉A它要断开连接(发送FIN)，A发送ACK，这里B发送ACK和B告诉A它要断开连接不能像三次握手一样合在一起的原因是B发送完ACK后，B仍可能有数据需要发送给A，确认B自己那里没有再要发送的数据后，B才会发送FIN给A。所以其实如果B在ACK的时候也把FIN发出去了，那其实可以理解为三次(前提是B此时正好也没有其他数据要发送了)。需要注意的是，当一台主机发送了FIN信号后，这台主机就失去了发送数据的能力，但是他还是可以回复ACK的，因为ACK的消息是没有数据的(只有segement header)
5. 为什么TCP4次挥手时等待为2MSL？https://www.zhihu.com/question/67013338/answer/248375813
6. TCP三次握手与四次挥手考点：https://www.zhihu.com/question/271701044/answer/398114686

Principles of Congestion Control

1. 讲了一下Congestion control的原因与解决办法，感觉不是很重要。

TCP Congestion Control

1. 拥塞控制需要解决三个问题：1.TCP sender如何检测到从它这一端到receiver端存在拥塞？ 2.检测到拥塞后，TCP sender如何限制传输的速度？3.TCP sender应该采取什么算法来根据端到端的拥塞情况改变它的发送速率？
2. 第一个问题：当TCP sender收到两种loss event的时候，证明传输路径中发生了拥塞，第一种信号是timeout，也就是在规定时间内没有收到某个segment的ACK并触发了timeout信号；第二种信号是sender端收到同一个segment的三个duplicate ACKs，这是证明传输路径中可能发生了丢包。当sender端检测到这两种信号的时候，sender端认为发生了拥塞，所以需要降低传输速率。反之，如果sender端收到ACK信号，证明线路中没有发生拥塞，且收到ACK的速度越快，证明线路越不可能拥塞，所以sender端在收到ACK时认为线路没有拥塞并且可以加快传输速率。TCP采取的策略就是每当收到ACK的时候，就提升自己的传输速率，直到收到loss event
3. 第二个问题：前面我们在讲流控的时候提到了receive window(rwnd)，在sender端还定义了一个变量congestion window(cwnd)，这个变量就是用来控制sender端的发射速率的(假设rwnd无限大的时候)。LastByteSent-LastByteAcked<=min{cwnd, rwnd}
4. 第三个问题：目前TCP采取的算法有：1.slow start 2.congestion avoidance 3.fast recovery，其中前两个是必须的，第三个是推荐的。
5. slow start虽然叫做slow start，但是它在传输速率上的改变是指数级的，也就是cwnd呈指数级增长(cwnd = cwnd + 1 MSS, 1MSS->2MSS->4MSS->8MSS)，这是因为刚开始发送数据的时候，发送速度距离我们的网络带宽还查得很远，我们需要一个函数去快速迫近临界值。如果在slow start阶段遇到loss event，就会设定ssthresh(slow start threshold)为cwnd/2，并将cwnd设定回默认值1MSS；如果在slow start阶段cwnd>=ssthresh，TCP会进入congestion avoidance阶段，原因是ssthresh的值是上一次遇到拥塞的一半，我们有理由相信我们已经逼近了拥塞的临界值，所以这个时候TCP选择更保守的congestion avoidance。
6. congestion avoidance阶段，cwnd是呈线性增长的(8MSS->9MSS->10MSS->11MSS)。如果遇到loss event，就回到slow start阶段
7. 如果我们不考虑fast recovery(TCP Tahoe)，那么TCP就会在slow start和congestion avoidance之间来回切换。但是我们会发现两种loss event其实是不同的，timeout的严重程度是比3 duplicatge ACKs更严重的，因此有人进一步提出了改造算法TCP reno，TCP reno引入了fast recovery，当sender收到三个duplicate ACKs，会设定ssthresh = cwnd/2，cwnd = ssthresh+3MSS(加三的意思是收到三个duplicate ACK)，并进入fast recovery状态，在这个状态下，cwnd每收到一个duplicate ACK就加1MSS(cwnd = cwnd + 1 MSS, 这个公式与cold start相同，但是这里不是指数级增长，而是线性增长，因为这里cwnd是在每收到一个duplicate ACK的情况下才会加1，从书中的TCP reno的图3.52也能看出来)。如果在fast recovery阶段发生timeout，那么没什么好说的，直接回到slow start，如果在fast recovery阶段收到了正常的ACK，那么证明网络已经正常，那么回到congestion avoidance。所以fast recovery就是TCP在收到三个duplicate ACKs以后，先把cwnd减为之前的一半，线性增长cwnd并尝试确认网络到底有没有拥塞，如果真的有问题就回到slow start重新开始，没问题(收到ACK)就回到congestion avoidance继续线性增长。这么一看，fast recovery(快速恢复)倒是名副其实，因为如果网络并没有拥塞，只是瞬间丢包，那么TCP可以很快回到稳定的congestion avoidance阶段，而略去了slow start阶段。
8. 网络上一段关于fast recovery的解释很好： Fast Recovery is now the last improvement of TCP. With using only Fast Retransmit, the congestion window is dropped down to 1 each time network congestion is detected. Thus, it takes an amount of time to reach high link utilization as before. Fast Recovery, however, alleviates this problem by removing the slow-start phase. Particulary, slow-start will be used only at the beginning of a connection and whenever an RTO(Retransmission TimeOut) period is expired.
   The reason for not performing slow-start after receiving 3 dup ACKs is that duplicate ACKs tell the sending side more than a packet has been lost. Since the receiving side can create a duplicate ACK only in the case that it receives an out-of-order packet, the dup ACK shows the sending side that one packet has been left out the network. Thus, the sending side does not need to drastically decrease cwnd down to 1 and restart slow-start. Moreover, the sender can only decrease cwnd to one-half of the current cwnd and increase cwnd by 1 each time it receives a duplicate ACK.
9. TCP是相对公平的，多个TCP连接，由于有congestion control，最终各个连接分得的bandwidth是相同的，这也符合了TCP的设计理念：TCP不是一个自私的协议，当拥塞发生的时候，要做自我牺牲。这点与UDP是不同的，UDP是不公平的(UDP都不是面向连接的，也没有拥塞控制，何谈公平？)。但是TCP的公平是相对的，公平是针对每个连接的，但对于用户来说并不公平，因为一个用户可以开始多个并行TCP连接。

The Network Layer: Data Plane

Overview of Network Layer

Forwarding and Routing: The Data and Control Planes

1. 网络层可以分为两个部分：数据平面(data plane)和控制平面(control plane)。数据平面负责的是转发(forwarding)，也就是当一个分组通过输入链路到达路由器的时候，路由器会决定这个分组发送到哪一个输出链路，转发的过程很快，通常只有几纳秒，一般是由硬件实现的；控制平面负责的是路由选择(routing)，也就是控制相应的路由器来规划出一条线路，确保分组最终能够从起点到达终点，一般由软件实现，所以控制平面控制的其实是数据平面。举个生活中的例子：控制平面就像是谷歌地图，为我们规划了一条线路；数据平面是开车的人，在每一个交叉路口都要进行一下具体的操作。
2. 网络层中最重要的元素是转发表(forwarding table)，每一个路由器中都有一个转发表，路由器通过查询转发表来确认某个分组该如何转发；转发表是由控制平面通过某些路由选择算法计算得出，分为传统方法和SDN(software-defined networking)方法。传统方法就是在每一个路由器中运行路由选择算法，路由器可以和相连的其他路由器交换信息，最终计算出转发表，本质上是一种局部最优解的路由选择算法；SDN方法就是全局考虑所有的路由器，通过远程控制器(remote controller)计算出最佳路径，并把相应的转发表发到每一个路由器中，是一种全局最优解。具体的算法会在第五章介绍。
3. 网络层提供了主机到主机的传输方法，也就是在主机到主机间有很多可能的路径，网络层告诉我们在遇到每一个路由的时候该如何继续传输数据，但是在一条数据链路上点对点的数据传输并不由网络层负责，而是由数据链路层负责。网络层就做了两件事：1.规划路线 2.转发。路由器实现了这两个功能，所以路由器属于网络层设备，路由器不需要实现运输层和应用层，因为他不需要实现进程到进程的传输，也不需要运行应用；链路层交换机没有这两个功能，所以交换机属于链路层设备

Network Service Model

1. 网络层不提供任何确保的服务，只提供尽力而为服务(best-effort service)
2. 在最开始我们介绍分组交换机(packet switches)的时候，我们说过常见的分组交换机有路由器(router)和链路层交换机(link-layer switch)，它们起到的作用都是转发。但是路由器是基于网络层datagram的header来做出转发的决定，所以他是网络层的设备；而链路层交换机是基于链路层frame的header来做出的转发决定，所以他是链路层的设备

What’s Inside a Router

1. 路由器内部结构图见书中图4.4，分为input ports, switching fabric, output ports, routing processor。其中input ports, switching fabric, output ports属于数据平面，是由硬件实现的；routing processor属于控制平面，使用软件方法实现路由选择。
2. input ports指的是路由器上物理的接口，主要有三个作用；1.分组从物理层到数据链路层 2.分组从数据链路层到网络层 3.查询转发表决定分组的output ports，排队并最终进入到switching fabric
3. switching fabric用来连接input ports和output ports
4. output ports也有三个作用：1.从switching fabric接收分组并进行排队缓存 2.分组从网络层到数据链路层 3.分组从数据链路层到物理层
5. routing processor属于控制平面，在使用传统方法的控制平面中，routing processor负责与相邻的路由器交换信息并计算出转发表；在使用SDN方法的控制平面中，routing processor负责与remote controller交互并得到转发表(转发表的计算是在remote controller中进行的)
6. 路由器中分组的转发分为两大类：destination-based forwarding和generalized forwarding。顾名思义，基于目的地的转发只根据目的地的IP地址进行转发的抉择，传统方法的控制平面使用这种转发方式；而一般性转发不仅会根据目的地IP地址，还会考虑其他因素(比如起点IP地址，起点或目的地的MAC地址等)来综合进行转发的抉择，SDN方法的控制平面使用这种转发方式

Input port processing and destination-based forwarding

1. Input port的更详细的作用见书中图4.5
2. 假设某一路由器使用传统控制平面，即使用destination-based forwarding，并且假设它有四个output ports，并且它的转发表如下所示：

   Destination address range                                                          link interface
   11001000 00010111 00010000 00000000 through 11001000 00010111 00010111 11111111          0
   11001000 00010111 00011000 00000000 through 11001000 00010111 00011000 11111111          1
   11001000 00010111 00011001 00000000 through 11001000 00010111 00011111 11111111          2
   otherwise                                                                                3

   这个转发表可以使用IP地址的prefix进行优化，prefix是通过比较IP地址区间的相同prefix得到的

   Prefix                             link interface
   11001000 00010111 00010                   0  
   11001000 00010111 00011000                1
   11001000 00010111 00011                   2
   otherwise                                 3

   通过prefix转发表，当我们拿到一个IP地址的时候，进行prefix match，就能知道输入的端口了，但是这里有一个问题，有些情况下同一个IP地址可以被多个prefix match，比如11001000 00010111 00011000 10101010这个IP地址就可以同时被1和2接口的prefix match。解决办法是使用longest prefix matching rule，也就是找到table中符合prefix match规则的最长的IP prefix。
3. 查询完转发表后，某一个分组已经知道了它的output ports，这个时候它需要进入switching fabric，但由于switching fabric可能正在处理其他分组，所以可能暂时需要在input port进行排队，具体排队的细节会在后面介绍

Switching

Switching主要分为三种：switching via memory, switching via a bus, switching via an interconnection network。具体细节见书中图4.6

Where does Queuing Occur

分组在input ports和output ports都会导致排队，具体见书中图4.9

Packet scheduling

由于在output ports存在排队，那么我们需要决定哪些分组出队列的先后顺序，常见的有FIFO(First-in-first-out), Priority Queueing, Round robin and weighted fair queueing(WFQ)

The Internet Protocal(IP): IPV4, Addressing, IPV6, and More

IPV4 Datagram Format

1. IPV4 Datagram的结构图见书中图4.16
2. Version number: 占4位，用来指明使用的IP的版本
3. Header length: 指明IP datagram的header长度，由于IPV4有Options选项，所以header的长度是不确定的，但是一般的IP datagram都没有options选项，所以一般header长度都是20字节
4. Type of service: 指明IP datagram的服务类型，比如datagram可能用于实时流量(网络直播)，或者非实时流量(邮件)
5. Dtagram length: 占16位，用来指明整个datagram的长度，所以理论上的最大长度是65535字节，但是由于链路层frame的长度限制，所以一般datagram都小于1500字节
6. Identifiew, flags, fragmentation offset: 用于fragmentation，值得注意的是只有IPV4使用了fragmentation，IPV6没有使用
7. Time-to-live: 确保datagram不会永远在网络中循环，没经过一个路由节点，TTL会减1，当变成0以后就会被路由器丢掉
8. Protocal: 指明了datagram包含的运输层segment使用的协议，6代表TCP，17代表UDP
9. Header checksum: 对IP datagram的header进行checksum。为什么TCP/UDP和IP都实现了checksum？1.IP的checksum只作用于header，TCP/UDP作用于整个segment 2.IP和TCP/UDP并不一定配套使用，有可能其他的传输层协议就没有checksum，所以有必要在IP协议也进行checksum
10. Source and destination IP address: destination IP address一般是通过DNS查询得到的
11. Options: 只有IPV4有，IPV6没有options选项
12. Data(payload): data可以包含TCP/UDP segment，也可以携带其他类型的数据，比如ICMP

IPV4 Datagram Fragmentation

1. 由于链路层的MTU并不一定相同(以太网是1500字节，别的链路层协议可能只有500字节)，IP datagram从起点到终点的过程中可能经过多种链路，在这种情况下，一个大的IP datagram会被拆分成多个小的datagram，这些小的datagram会在终点处重组。IPV6没有使用这种技术，而是如果数据链路的MTU不够使用，那么这个datagram就会发送失败并通知发送端以更小的长度来发送

IPV4 addressing

1. 主机或者路由器与数据链路相连的边界叫做接口(可以理解为网卡)，IP地址是与网卡绑定的，而不是主机。由于主机一般只有一个网卡，所以我们总是说某某主机的IP地址是多少，但对于路由器来说，每一个进出接口都会被绑定一个IP，所以路由器总是与多个IP地址绑定的
2. 子网的定义：如果将接口从主机和路由器剥离，形成的一个个的isolated island就是子网，见书中图4.19。一个很好的子网的例子就是公司的内网，我们假设某个公司内网与互联网相连只通过一个路由器，内网之间的连接都是通过交换机(以太网)或者无线连接的，假设我们把内网到互联网的端口断掉了，内网就成了一个isolated island，只能内网之间交换信息，而不能与外界通讯了。子网一个很大的特点就是子网内的主机通讯不需要通过路由器，不同子网间通讯需要路由器的参与
3. 那么如果我们有多台主机的IP地址，如何判断它们是不是在一个子网里呢？这是由子网掩码(subnet mask)来定义的，子网掩码的表示方法有两种：223.1.1.0/24，这里的/24就是子网掩码，表示这个子网中IP的前24位都是相同的；另一种表示方法是255.255.255.0，表示的同一个意思，如果把255.255.255.0和IP地址进行与运算，如果结果都是一样的，代表这些IP在同一个子网中
4. 如果a.b.c.d/x代表一个子网，那么我们一般说这个子网IP地址的前x位是它的网络号，网络号对于子网内的IP都是相同的。剩下的32-x位是主机号，子网中共有2的(32-x)次方个IP地址，子网中的每台主机可以分得一个IP地址
   5， 大的子网可以继续分成小的子网：假设某一个ISP得到的大的子网是200.23.16.0/20，那么这个子网共有2的12次方，也就是4096个IP地址，现在ISP可以把这个子网分给很多小公司，每个小公司有2的9次方，也就是512个IP地址，那么这个大的子网可以分成8个小的子网，子网地址分别是：200.23.16.0/23, 200.23.18.0/23 … 200.23.30.0/23
5. https://www.zhihu.com/question/29723388/answer/238290373. 前面我们说过，子网的主机间可以直接通讯，因为他们的IP地址在经过子网掩码与运算后相同，两台主机知道互相是在同一个子网(网段)里的，所以直接发送ARP请求对方主机的MAC地址后即可通信(第六章会学习)
6. 当一个组织或公司被分配了一个子网的地址后，该如何给网络中的主机分配IP地址呢，通常使用的是DHCP(Dynamic Host Configuration Protocal)，这个协议用来为主机动态的分配IP地址。DHCP是一个client-server协议，在子网中会有一个DHCP server，负责分配IP地址。过程主要分为4步(书中图4.24)：1.DHCP server discovery，新加入的未分配IP地址的主机的IP地址是0.0.0.0，通过向255.255.255.255这个广播IP地址来告诉内网中所有主机自己需要一个新的IP 2.DHCP server offer，内网中的DHCP server收到广播的请求后指定一个待分配的IP地址，并且也通过255.255.255.255进行广播 3.DHCP request，新加入的主机收到DHCP server分配的IP地址后，再一次向255.255.255.255发送广播，表示自己要使用这个IP地址 4.DHCP ACK，同样的，DHCP server向255.255.255.255发送广播表示同意client使用这个地址。可以看到，在DHCP协议中，广泛的使用了255.255.255.255这个IP地址的广播作用，这是因为新加入的主机还没有被分配IP地址，还不能使用内网IP地址进行通信，所以只能使用广播
7. DHCP：https://www.zhihu.com/question/267097519
8. 关于0.0.0.0, 127.0.0.1, 本地IP：0.0.0.0 在不同的情况下有不同的意义，例如，在socket bind中表示所有可用的interface；在网卡初始化时表示“还未获得IP”。比如一个程序选择监听在0.0.0.0，则表示要监听在所有的自己可用的IP（所有的网卡）上；在运行DHCP client之前将网卡IP设置为0.0.0.0，则表示此网卡要参与DHCP的IP申请过程。首先我们要先知道一个概念，凡是以127开头的IP地址，都是回环地址（Loop back address），其所在的回环接口一般被理解为虚拟网卡，并不是真正的路由器接口。所谓的回环地址，通俗的讲，就是我们在主机上发送给127开头的IP地址的数据包会被发送的主机自己接收，根本传不出去，外部设备也无法通过回环地址访问到本机。本机IP通常仅指在同一个局域网内，能同时被外部设备访问和本机访问的那些IP地址（可能不止一个）。像127.0.0.1这种一般是不被当作本机IP的。本机IP是与具体的网络接口绑定的，比如以太网卡、无线网卡或者PPP/PPPoE拨号网络的虚拟网卡，想要正常工作都要绑定一个地址，否则其他设备就不知道如何访问它。
9. 现在有两台pc在同一个局域网内，分别为pc1与pc2，pc1上有一个网卡，IP地址为192.168.10.128
   pc1中sever监听127.0.0.1，则pc1中的client可以连上127.0.0.1，但是连不上192.168.10.128；而pc2中client什么都连不上。
   pc1中sever监听192.168.10.128，则pc1中的client可以连上192.168.10.128，但是连不上127.0.0.1；而pc2中client能连上192.168.10.128。
   pc1中sever监听0.0.0.0，则pc1中的client可以连上127.0.0.1和192.168.10.128，pc2中的client能连上192.168.10.128。

Network Address Translation(NAT)

1. 由于IPV4地址是有限的，并不能保证每个主机都能分到，比如在家庭网络中，ISP往往只提供给我我们一个IP地址，但是我们有多个主机(电脑，手机等)，这个时候就需要使用NAT技术，顾名思义，NAT是一种将IP地址进行转译来达到扩展私有IP地址的目的，注意，这里扩展的只是私有IP地址，这个私有IP地址只在我们私有网络中才是有意义的。
2. NAT的工作原理是，私有网络(局域网，LAN)是一个子网，使用私有IP地址，当私有网络中的主机想要与互联网通讯的时候，在路由器处会进行(私有IP地址，端口)与(公共IP地址，端口)的转译，外界的互联网是看不到我们内部的私有IP地址的，它只是以为在于我们公有IP地址进行通讯。比如我们私有网络中有两台主机192.168.0.1和192.168.0.2，两台主机一台使用100端口浏览网页，一台使用200端口发邮件，那么这两个网络连接在路由器处会进行转译，假设我们的公有IP是67.72.0.3，那么路由器会使用两个端口，继续进行这两个网络请求，同时记录对应的NAT记录：(192.168.0.1, 100 : 67.72.0.3, 1), (192.168.0.2, 200 : 67.72.0.3, 2)。书中的图4.25清晰地表示了NAT的使用。由于端口号有16位，所以理论上仅通过一个公有IP地址，NAT支持65535个连接。
3. NAT被广泛使用在现在的私有网络中，但是有些反对的声音：端口是应该用来标记进程的，而不是用来标记主机的，这会造成某些问题，比如如果我们私有网络中的主机是一个服务器，他需要先接收请求后才能发送数据，由于请求进来的时候，NAT的翻译关系还不存在，所以是无法找到内网的主机的，这种情况下需要使用NAT穿透技术。

IPV6

1. IPV6的Datagram的结构图见书中图4.26
2. IPV6与IPV4网络之间传递datagram，需要使用tunneling技术，简单来说就是在一个IPV4 datagram的data部分塞入一个IPV6的datagram，这样IPV6的datagram就可以在IPV4的网络中传播了。

Generalized Forwarding and SDN

1. 这一节介绍的是使用SDN控制平面并采用Generalized Forwarding。前面我们介绍过传统的控制平面，它是通过router本地运行routing算法来计算forwarding table，并且forwarding table只基于目的地IP地址；而SDN控制平面使用远程remote controller来计算forwarding table，forwarding table的计算也不仅仅是根据目的地IP地址，而是还可能根据其它的headers(比如出发地IP地址，MAC地址等)，所以它的计算量是相对更大的，这也是这种forwarding table采用remote controller远程计算的原因，另外Generalized Forwarding除了能提供分组转发功能外，它还能提供其它功能，比如分组丢弃(防火墙功能)或者改变分组的头部(NAT功能)等。所以总的来说，SDN控制平面是未来网络的发展趋势。

The Link Layer and LANs

Introduction to the Link Layer

1. 数据链路层与传输层的类比：假设一个旅游代理正在为一个旅行团规划从大连到纳什维尔的路线，规划的结果是从大连到北京做高铁，从北京到芝加哥做飞机，从芝加哥到纳什维尔做大巴。在这个例子中，旅游团是datagram，每一个transportation segment是一个链路，交通方式是链路层协议，旅游代理是路由选择协议。也就是说传输层只负责路由的规划，但是datagram在每一条链路中是如何从起点传到终点的是由链路层负责的
2. 链路层大部分实现在网卡(network adapter, or network interface card)处，90年代的时候，网卡都是一张单独的板子，但是现代的网卡都已经被集成到主板上了
3. 链路层有两种信道，一种是广播信道，也就是frame会被发送给所有连接的主机；一种是点对点信道，也就是frame只会被发送给对应的主机

Error-Detection and Correction Techniques

1. 主要分为三种，第一种是Parity check，也就是约定好该使用奇校验或者偶校验，接收端判断接收到的二进制的数据是不是奇数或者偶数，不是的话说明传输过程中一定出现了问题，但是这种方法并不保险，因为如果是多个bits发生改变，结果可能检测不出来。改进的的方法有二维奇偶校验
2. 第二种是我们已经见过的checksum校验，第三种是链路层最常用的CRC校验

Multiple Accesss Links and Protocals

1. 本章介绍了广播信道的实现方式，比如时分，频分或者更高级的方法，具体内容见书

Switched Local Area Networks

Link-Layer Addressing and ARP

1. 主机或者路由器的网卡都有一个写死的链路层地址，我们称为MAC地址，如果一台主机或者路由器有多个网卡(接口)，那么每一个接口都会有一个IP地址，同时也会有一个MAC地址。MAC地址是与网卡的硬件绑定的，一个网卡生产出来，它的MAC地址就不能改变了，并且世界上没有任何两个网卡有相同的MAC地址。我们可以把MAC地址理解为身份证号，它是不会变的，IP地址理解为邮编，它是我们连接到互联网以后被分配的，如果一台设备没有连接到互联网，那么他就没有IP地址，但是MAC地址永远存在
2. 链路层使用FF-FF-FF-FF-FF-FF做为广播的MAC地址，也就是说任何发送到这个MAC地址的frame都会被广播到子网中的其他设备上，前面我们讲过的DHCP就是通过这种方式进行广播的，它的IP destination是255.255.255.255，就对应了FF-FF-FF-FF-FF-FF这个MAC地址
3. 我们在一条数据链路上传输frame，需要知道端点处两台设备的MAC地址，本机的MAC地址是已知的，但是终点设备的MAC地址是未知的，我们一般知道的是终点设备的IP地址，这个时候需要使用Address Resolution Protocal(ARP)协议。子网中每台主机和路由器中都会维护一个ARP表，里面存有子网中设备的IP地址与MAC地址的映射关系，如果我们发送的终点的IP地址已经在映射表中，那么很简单，我们拿到终点的MAC地址，写入frame中即可发送，但是如果映射表中没有终点的IP地址怎么办？这个时候就需要使用链路层的广播能力，起点会向FF-FF-FF-FF-FF-FF发送一个ARP请求，询问子网中所有的主机和路由器：你们的IP地址是不是终点的IP地址，是的话返回你得MAC地址，终点的主机或者路由器收到这个ARP请求后确认自己的IP与请求的相同，于是返回一个ARP response，里面写有自己的MAC地址。这样起点就有了终点的MAC地址，并且这个映射关系会被缓存在ARP表中，方便下次使用。
4. 链路层的广播只对子网内的路由器和主机有效，路由器连接的外网是收不到广播的，路由器起到了隔绝广播的作用，使得广播只在子网中有作用。ARP使用了广播技术，所以ARP协议也只能查询子网中IP与MAC的映射关系
5. 计算机网络中的通信可以分为三种：主机自己与自己通信，同一子网(网段)中的主机间通信，不同子网的主机间通信。自己与自己通信很简单，直接发给自己就好了。对于另外两种，首先主机需要判断目的地主机与自己在不在一个子网中，这是通过什么判断的呢？通过前面我们介绍的子网掩码，通过将子网掩码与两个IP做与运算，如果相同的话代表两台主机在同一个子网(网段)。如果在同一个子网，那么事情很简单，通过ARP协议获取目的地的MAC地址，然后发送frame即可。如果不在一个子网中，见图6.19，那么发送端主机会去请求子网中默认设备(一般是路由器)的MAC地址，由于路由器与发送端主机在同一个子网中，可以使用ARP协议获取路由器的MAC地址，frame被发送给路由器，值得注意的是，这个frame中包含的datagram的destination IP是接收端的IP，但是frame的destination MAC是路由器的MAC地址。路由器的input interface接收到这个frame以后，传递到网络层变成datagram，路由器的网络层前面我们介绍过，存在一个forwarding table，forwarding table查看datagram的destination IP得出需要forward的output interface，output interface与接收端在同一个子网中，可以使用ARP协议查到接收端的MAC地址，把这个frame发送到接收端。
6. 我在学习的过程中遇到一个不理解的问题，frame在每条数据链路的传输都需要先知道链路终点的MAC地址，一般是通过ARP协议查询IP地址与MAC地址的映射来得到的。假设某个dataframe需要经过多个路由器才能到达终点，那么意味着在每个路由器节点，datagram需要获知下一个路由器节点的IP地址，这样才能根据IP地址获得下一个路由器节点的MAC地址，但是书中的forwarding table并没有下一个节点的IP地址，通过查询发现forwarding table中是会存下一个节点的IP地址的，这样的话整个流程是说得通的。https://www.zhihu.com/question/55015810

Link-Layer Switches

1. 链路层交换机与路由器都是分组交换机(packet switches)，不同的是路由器工作在第三层，根据IP地址进行datagram转发，并且不是即插即用的，因为需要通过路由算法或者SDN配置forwarding table；而链路层交换机是根据MAC地址进行frame转发，是即插即用的。
2. 链路层交换机对于子网中的主机和路由器是透明的，也就是说子网中的主机和路由器根本不知道链路层交换机的存在，所以链路层交换机是没有MAC地址的！ 那么链路层交换机是怎么做到在发送端与接收端之间转发frame的呢？答案是与路由器的forwarding table类似，链路层交换机中也有一个forwarding table，但是是根据MAC地址来进行interface的选择
3. 那么一个很关键的问题就是：链路层交换机中的forwarding table是怎么生成的呢？是和网络层一样通过路由算法或者SDN设置的吗？答案是否定的。链路层交换机使用了子网的广播技术，当接收端的MAC地址不在forwarding table中时，链路层交换机会向所有的interface广播这条frame，同时记录发送端的MAC地址和它进入的interface。所以如果一个子网中的主机间不停的通过交换机发送数据，那么他的forwarding table是会不断被写满的，这叫做self-learning。链路层交换机之所以能采用这种方式的原因是；子网可以使用广播，且子网中设备较少，试想如果我们的网络层也使用广播技术，一旦MAC地址为止，就向全世界的网卡发送这条消息，那是多么可怕

Ethernet, Virtual Local Area Network

1. 这些内容如果工作中遇到了，可以再深入了解

Retrospective: A Day in the Life of a Web Page Request

1. 书中的英文解释和图例都很好，这里不再翻译
   One way then to take this “big picture” view is to identify the many (many!) protocols that are involved in satisfying even the simplest request: downloading a Web page. Figure 6.32 illustrates our setting: a student, Bob, connects a laptop to his school’s Ethernet switch and downloads a Web page (say the home page of www.google.com). As we now know, there’s a lot going on “under the hood” to satisfy this seemingly simple request. A Wireshark lab at the end of this chapter examines trace files containing a number of the packets involved in similar scenarios in more detail.

6.7.1 Getting Started: DHCP, UDP, IP, and Ethernet

Let’s suppose that Bob boots up his laptop and then connects it to an Ethernet cable connected to the school’s Ethernet switch, which in turn is connected to the school’s router, as shown in Figure 6.32. The school’s router is connected to an ISP, in this example, comcast.net. In this example, comcast.net is providing the DNS service for the school; thus, the DNS server resides in the Comcast network rather than the school network. We’ll assume that the DHCP server is running within the router, as is often the case.
When Bob first connects his laptop to the network, he can’t do anything (e.g., download a Web page) without an IP address. Thus, the first network-related
action taken by Bob’s laptop is to run the DHCP protocol to obtain an IP address, as well as other information, from the local DHCP server:

1. The operating system on Bob’s laptop creates a DHCP request message (Section 4.3.3) and puts this message within a UDP segment (Section 3.3) with destination port 67 (DHCP server) and source port 68 (DHCP client). The UDP segment is then placed within an IP datagram (Section 4.3.1) with a broadcast IP destination address (255.255.255.255) and a source IP address of 0.0.0.0, since Bob’s laptop doesn’t yet have an IP address.
2. The IP datagram containing the DHCP request message is then placed within an Ethernet frame (Section 6.4.2). The Ethernet frame has a destination MAC addresses of FF:FF:FF:FF:FF:FF so that the frame will be broadcast to all devices connected to the switch (hopefully including a DHCP server); the frame’s source MAC address is that of Bob’s laptop, 00:16:D3:23:68:8A.
3. The broadcast Ethernet frame containing the DHCP request is the first frame sent by Bob’s laptop to the Ethernet switch. The switch broadcasts the incoming frame on all outgoing ports, including the port connected to the router.
4. The router receives the broadcast Ethernet frame containing the DHCP request on its interface with MAC address 00:22:6B:45:1F:1B and the IP datagram is extracted from the Ethernet frame. The datagram’s broadcast IP destination address indicates that this IP datagram should be processed by upper layer protocols at this node, so the datagram’s payload (a UDP segment) is thus demultiplexed (Section 3.2) up to UDP, and the DHCP request message is extracted from the UDP segment. The DHCP server now has the DHCP request message.
5. Let’s suppose that the DHCP server running within the router can allocate IP addresses in the CIDR (Section 4.3.3) block 68.85.2.0/24. In this example, all IP addresses used within the school are thus within Comcast’s address block. Let’s suppose the DHCP server allocates address 68.85.2.101 to Bob’s laptop. The DHCP server creates a DHCP ACK message (Section 4.3.3) containing this IP address, as well as the IP address of the DNS server (68.87.71.226), the IP address for the default gateway router (68.85.2.1), and the subnet block (68.85.2.0/24) (equivalently, the “network mask”). The DHCP message is put inside a UDP segment, which is put inside an IP datagram, which is put inside an Ethernet frame. The Ethernet frame has a source MAC address of the router’s interface to the home network (00:22:6B:45:1F:1B) and a destination MAC address of Bob’s laptop (00:16:D3:23:68:8A).
6. The Ethernet frame containing the DHCP ACK is sent (unicast) by the router to the switch. Because the switch is self-learning (Section 6.4.3) and previously received an Ethernet frame (containing the DHCP request) from Bob’s laptop, the switch knows to forward a frame addressed to 00:16:D3:23:68:8A only to the output port leading to Bob’s laptop.
7. Bob’s laptop receives the Ethernet frame containing the DHCP ACK, extracts the IP datagram from the Ethernet frame, extracts the UDP segment from the IP datagram, and extracts the DHCP ACK message from the UDP segment. Bob’s DHCP client then records its IP address and the IP address of its DNS server. It also installs the address of the default gateway into its IP forwarding table (Section 4.1). Bob’s laptop will send all datagrams with destination address
   outside of its subnet 68.85.2.0/24 to the default gateway. At this point, Bob’s laptop has initialized its networking components and is ready to begin processing the Web page fetch. (Note that only the last two DHCP steps of the four presented in Chapter 4 are actually
   necessary.)

6.7.2 Still Getting Started: DNS and ARP

When Bob types the URL for www.google.com into his Web browser, he begins the long chain of events that will eventually result in Google’s home page being displayed by his Web browser. Bob’s Web browser begins the process by creating a TCP socket (Section 2.7) that will be used to send the HTTP reques (Section 2.2) to www.google.com. In order to create the socket, Bob’s laptop will need to know the IP address of www.google.com. We learned in Section 2.5, that the DNS protocol is used to provide this name-to-IP-address translation service.
8. The operating system on Bob’s laptop thus creates a DNS query message (Section 2.5.3), putting the string “www.google.com” in the question section of the DNS message. This DNS message is then placed within a UDP segment with a destination port of 53 (DNS server). The UDP segment is then placed within an IP datagram with an IP destination address of 68.87.71.226 (the address of the DNS server returned in the DHCP ACK in step 5) and a source
IP address of 68.85.2.101.
9. Bob’s laptop then places the datagram containing the DNS query message in an Ethernet frame. This frame will be sent (addressed, at the link layer) to the gateway router in Bob’s school’s network. However, even though Bob’s laptop knows the IP address of the school’s gateway router (68.85.2.1) via the DHCP ACK message in step 5 above, it doesn’t know the gateway router’s MAC address. In order to obtain the MAC address of the gateway router, Bob’s laptop
will need to use the ARP protocol (Section 6.4.1).
10. Bob’s laptop creates an ARP query message with a target IP address of 68.85.2.1 (the default gateway), places the ARP message within an Ethernet frame with a broadcast destination address (FF:FF:FF:FF:FF:FF) and sends the Ethernet frame to the switch, which delivers the frame to all connected devices, including the gateway router.
11. The gateway router receives the frame containing the ARP query message on the interface to the school network, and finds that the target IP address of 68.85.2.1 in the ARP message matches the IP address of its interface. The gateway router thus prepares an ARP reply, indicating that its MAC address of 00:22:6B:45:1F:1B corresponds to IP address 68.85.2.1. It places the ARP reply message in an Ethernet frame, with a destination address of
00:16:D3:23:68:8A (Bob’s laptop) and sends the frame to the switch, which delivers the frame to Bob’s laptop.
12. Bob’s laptop receives the frame containing the ARP reply message and extracts the MAC address of the gateway router (00:22:6B:45:1F:1B) from the ARP reply message.
13. Bob’s laptop can now (finally!) address the Ethernet frame containing the DNS query to the gateway router’s MAC address. Note that the IP datagram in this frame has an IP destination address of 68.87.71.226 (the DNS server), while the frame has a destination address of 00:22:6B:45:1F:1B (the gateway router). Bob’s laptop sends this frame to the switch, which delivers the frame to the gateway router.

6.7.3 Still Getting Started: Intra-Domain Routing to the DNS Server

14. The gateway router receives the frame and extracts the IP datagram containing the DNS query. The router looks up the destination address of this datagram (68.87.71.226) and determines from its forwarding table that the datagram should be sent to the leftmost router in the Comcast network in Figure 6.32. The IP datagram is placed inside a link-layer frame appropriate for the link connecting the school’s router to the leftmost Comcast router and the frame is sent over this link.
15. The leftmost router in the Comcast network receives the frame, extracts the IP datagram, examines the datagram’s destination address (68.87.71.226) and determines the outgoing interface on which to forward the datagram toward the DNS server from its forwarding table, which has been filled in by Comcast’s intra-domain protocol (such as RIP, OSPF or IS-IS, Section 5.3) as well as the Internet’s inter-domain protocol, BGP (Section 5.4).
16. Eventually the IP datagram containing the DNS query arrives at the DNS server. The DNS server extracts the DNS query message, looks up the name www.google.com in its DNS database (Section 2.5), and finds the DNS resource record that contains the IP address (64.233.169.105) for www.google.com. (assuming that it is currently cached in the DNS server). Recall that this cached data originated in the authoritative DNS server (Section 2.5.2) for googlecom. The DNS server forms a DNS reply message containing this hostname-to-IPaddress mapping, and places the DNS reply message in a UDP segment, and the segment within an IP datagram addressed to Bob’s laptop (68.85.2.101). This datagram will be forwarded back through the Comcast network to the school’s router and from there, via the Ethernet switch to Bob’s laptop.
17. Bob’s laptop extracts the IP address of the server www.google.com from the DNS message. Finally, after a lot of work, Bob’s laptop is now ready to contact the www.google.com server!

6.7.4 Web Client-Server Interaction: TCP and HTTP

18. Now that Bob’s laptop has the IP address of www.google.com, it can create the TCP socket (Section 2.7) that will be used to send the HTTP GET message (Section 2.2.3) to www.google.com. When Bob creates the TCP socket, the TCP in Bob’s laptop must first perform a three-way handshake (Section 3.5.6) with the TCP in www.google.com. Bob’s laptop thus first creates a TCP SYN segment with destination port 80 (for HTTP), places the TCP segment inside an IP datagram with a destination IP address of 64.233.169.105 (www.google.com), places the datagram inside a frame with a destination MAC address of 00:22:6B:45:1F:1B (the gateway router) and sends the frame to the switch.
19. The routers in the school network, Comcast’s network, and Google’s network forward the datagram containing the TCP SYN toward www.google.com, using the forwarding table in each router, as in steps 14–16 above. Recall that the router forwarding table entries governing forwarding of packets over the inter-domain link between the Comcast and Google networks are determined by the BGP protocol (Chapter 5).
20. Eventually, the datagram containing the TCP SYN arrives at www.google.com. The TCP SYN message is extracted from the datagram and demultiplexed to the welcome socket associated with port 80. A connection socket (Section 2.7) is created for the TCP connection between the Google HTTP server and Bob’s laptop. A TCP SYNACK (Section 3.5.6) segment is generated, placed inside a datagram addressed to Bob’s laptop, and finally placed inside a link-layer frame
    appropriate for the link connecting www.google.com to its first-hop router.
21. The datagram containing the TCP SYNACK segment is forwarded through the Google, Comcast, and school networks, eventually arriving at the Ethernet card in Bob’s laptop. The datagram is demultiplexed within the operating system to the TCP socket created in step 18, which enters the connected state.
22. With the socket on Bob’s laptop now (finally!) ready to send bytes to www.google.com, Bob’s browser creates the HTTP GET message (Section 2.2.3) containing the URL to be fetched. The HTTP GET message is then written into the socket, with the GET message becoming the payload of a TCP segment. The TCP segment is placed in a datagram and sent and delivered to www.google.com as in steps 18–20 above.
23. The HTTP server at www.google.com reads the HTTP GET message from the TCP socket, creates an HTTP response message (Section 2.2), places the requested Web page content in the body of the HTTP response message, and sends the message into the TCP socket.
24. The datagram containing the HTTP reply message is forwarded through the Google, Comcast, and school networks, and arrives at Bob’s laptop. Bob’s Web browser program reads the HTTP response from the socket, extracts the html for the Web page from the body of the HTTP response, and finally (finally!) displays the Web page!

Security in Computer Networkss

What is Network Security

1. 网络安全的三个要素： 1.机密性 2.消息完整性 3.端点鉴别
2. Confidentiality: 机密性指的是只有发送端和接收端才能知道传输的消息的含义，中间人是不能知道的，那么消息的传输就需要加密
3. Message integrity：消息完整性指的是接收端需要确定它收到的消息是完整的，而不是被恶意或者偶然缺失掉了
4. End-point authentication：发送端与接收端互相确认彼此身份

Principles of Cryptography

1. 对称加密算法：对称加密算法的原理是发送端与接收端事先沟通好一个加密解密所用的key，发送端用这个key，使用约定好的加密算法将信息加密后，接收端使用相同的key将原本的信息解密出来。最简单的对称加密算法就是移项式密码，所有的字母都由他后面第k个字母代替，接收端接收到加密信息后，把每个字母向前移k即可得到原信息。常见的对称加密算法有AES(Advanced Encryption Standard)。对称加密算法最大的问题就是在计算机网络中，发送端和接收端如何沟通好对称加密使用的key。
2. 为了生成一个只有发送端和接收端才知道的key，DH秘钥交换算法应运而生，算法的数学细节这里不多讨论具体见：https://www.wst.space/ssl-part-2-diffie-hellman-key-exchange/. 过程是发送端与接收端分别生成一个秘钥，各自进行某些运算后发给对方，然后各自再使用收到的信息加上自己的秘钥就能生成一个只有彼此知道的秘钥key，即使中间人知道了发送端和接收端发送的信息，也无法猜测出两端各自的秘钥，也就猜测不出最终生成的秘钥key。
3. 非对称加密算法：非对称加密算法的原理是接收端生成一个公钥keyA和私钥keyB，使用公钥加密的信息，只有使用私钥才能进行解密，这样发送端可以把想要加密的信息用公钥进行加密，接收端收到加密信息后使用私钥进行解密。这其中的数学原理不多讨论，一个通俗易懂的原理在这：https://www.zhihu.com/question/33645891/answer/192604856?utm_source=ZHShareTargetIDMore&utm_medium=social&utm_oi=632331097145479168. 最著名的非对称加密算法是RSA算法。
4. TLS在加密消息的时候，通常还是使用对称加密算法，因为它的性能最好，秘钥交换算法和非对称加密算法用来生成对称加密算法所需要使用的key。

Message Integrity and Digital Signatures

Cryptographic Hash Function

1. 散列(哈希)函数可以把一串信息哈希成固定长度的内容，哈希是不可逆的，主要用来保障数据完整性，即发信人将原始消息和哈希值一起发送，收信人通过相同的哈希函数来校验原始数据是否完整，但是仅用哈希函数是不够的，后面我们会介绍。哈希算法主要有MD4、MD5、SHA。
   MD4 1990年 输出128位 （已经不安全）
   MD5 1991年 输出128位 （已经不安全）
   SHA-0 1993年 输出160位 （发布之后很快就被NSA撤回，是SHA-1的前身）
   SHA-1 1995年 输出160位 （已经不安全）
   SHA-2包括SHA-224、SHA-256、SHA-384，和 SHA-512，分别输出224、256、384、512位。 (目前安全)

Message Authentication Code

1. 假设现在发送端要发送一段信息m，并且使用哈希算法，发出一段延长的信息(m, H(m))，接收端通过同样的哈希算法计算出H(m)=H(m)，确认信息是完整的，但是有一个问题是，我们无法确认接收端收到的m，确实是由发送端发来的：比如中间人可以截住发送的信息，然后自己发送一个(m’, H(m’))给接收端。解决的办法是发送端和接收端使用一个相同的secrets，接收端发送的时候，发送(m, H(m+s))，然后接收端验证H(m+s)=H(m+s)。H(m+s)被叫做message authentication code(MAC)，现在主流的MAC是HMAC

SSL/TLS详解

1. SSL/TLS历史：SSL协议最早由NetScape公司在90年代提出，经过几个版本的发展(SSL1.0, SSL2.0, SSL3.0)在99年的时候，SSL3.0被纳入网络标准并更名为TLS1.0，随后推出了TLS1.1, TLS1.2和TLS1.3。TLS协议工作在应用层和传输层之间。
2. TLS的基本原理是使用对称加密，对称加密的秘钥由非对称加密或者秘钥交换算法生成，为了更好的解释数字证书的作用，后面的介绍默认TLS使用非对称加密+对称加密。假设服务器端有非对称加密的公钥A和私钥A’，当客户端想要与服务器端建立TLS连接的时候，会先发送一个client Hello，服务器端接收到client Hello消息后，会向客户端发送公钥A’，随后客户端使用公钥A’加密自己生成的一个秘钥X，并发送给服务器端，服务器端使用私钥A’解密信息，得到秘钥X。至此，客户端和服务器端达成了一致，获得了对称加密所需使用的X，后面的消息传递使用X加密即可。
3. 上面的原理中有一个很严重的漏洞，就是无法防范中间人攻击，假设有一个中间人在截住了服务器端发送的公钥A，并且替换成了自己生成的公钥B，客户端毫不知情的使用公钥B对秘钥X进行了加密并发送给服务器端，此时中间人再一次截住了这段返回信息，并使用自己的私钥B’解密处秘钥X，同时在使用公钥A加密X返回给服务器端，那么就会造成一个很严重的后果：客户端和服务器端在毫不知情的情况下，被中间人得知了秘钥X，后续两者的对称加密在中间人眼里完全是无效的！所以现在，我们的问题就是：如何证明服务器端的公钥真的来自于服务器端？解决办法是使用数字证书(certificate)和数字签名(digital signature)，服务器的公钥写在数字证书中。
4. 服务器的数字证书主要包含以下信息：1.Subject name(即该数字证书是签发给谁的) 2.Issuer name(包括签名算法，签发组织等) 3.Public key info(包括公钥所使用的的加密算法，公钥，数字签名等) 4.其他信息，这些细节随便点开任意一个HTTPS网站的证书即可看到。数字证书中除了数字签名，其他都是明文的，所以客户端在拿到服务器端的数字证书后，是能够直接读取到服务器端的公钥的。数字证书是怎么证明证书中公钥的来源者的身份的呢？通过数字签名。我们将数字证书中除了签名以外的明文内容设为P，对其使用哈希函数得到H(P)，数字证书的签发者有一对非对称秘钥，签发者使用私钥对H(P)进行加密，得到数字签名。客户端在收到数字证书后，会使用签发者的公钥对数字签名进行解密，得到H，同时客户端会使用相同的哈希函数计算H(P)，如果发现H==H(P)，那么证明数字证书确实来自于服务器，并且内容没有被改动，那么自然而然数字证书中的公钥也就是可信的了。 https://github.com/ShiyuLiuColumbia/diagram/blob/main/how-do-digital-signatures-and-digital-certificates-work-together-in-ssl.png
5. 上面我们提到过，客户端会使用签发者的公钥对数字签名进行解密，那么一个问题来了：我们怎么知道签发者的公钥是可信的呢？其实我们并不能确定，所以上面的数字证书的签名其实可能是坏人使用它的私钥伪造的假签名。这就引出了证书链认证的问题：在我们的计算机中，内置了很多我们默认信任的根证书(root certificate)，它们来自于各个证书颁发机构(CA, Certificate Authority)。证书颁发机构保存有一对只有它自己知道的非对称秘钥K和K’。这些证书颁发机构生成的根证书的数字签名是由自己的私钥K’签署的，所以也叫做自签名证书。假设我们的服务器的证书的签发者就是CA，那么我们可以确认签发者的公钥(根证书)是可信的；但是很多情况下，服务器的证书并不是由CA签发的，而是由中间机构签发的，而中间机构的证书才是有CA签发的。那么证书链的认证是这样的( https://github.com/ShiyuLiuColumbia/diagram/blob/main/Chain_Of_Trust.svg )：
   客户端收到 http://baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 http://baidu.com 证书是否可信。于是，客户端根据 http://baidu.com 证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后根据 http://baidu.com 证书中提供的中间证书url请求该中间证书。
   请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，如果发现验证通过，就认为该中间证书是可信的。
   “GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 http://baidu.com 证书的可信性，如果验证通过，就可以信任 http://baidu.com 证书。
   在这四个步骤中，最开始客户端只信任根证书“GlobalSign Root CA”证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 http://baidu.com 证书，于是客户端也信任 http://baidu.com 证书
6. 数字证书的原理：https://www.zhihu.com/question/24294477/answer/74783418?utm_source=ZHShareTargetIDMore&utm_medium=social&utm_oi=632331097145479168
   https://zhuanlan.zhihu.com/p/43789231?utm_source=ZHShareTargetIDMore&utm_medium=social&utm_oi=632331097145479168
7. TTL协议各个步骤详解：前面我们简单介绍了TTL的原理，但是其实TTL协议的步骤和细节很复杂，具体见：https://xz.aliyun.com/t/2531, https://www.wst.space/ssl-part-4-tls-handshake-protocol/。 其中有几个需要注意的点：
   • Pre-Master Secret根据选择的加密套件的不同，产生的方法也不同，如果使用的是非对称加密算法(RSA)，那么Pre-Master Secret就完全由client生成并通过证书里的公钥加密发送给server；如果使用的是秘钥交换算法(DH)，那么client和server互相传递秘钥即可生成Pre-Master Secret，这个时候证书里的公钥不再用于加密(因为client不用像RSA那样生成Pre-Master Secret)，而是只用于对传递的秘钥进行签名，以确保两端发送的秘钥没有被篡改
   • TLS的Client Key Exchange和Server Key Exchange都是可选的步骤，原因就是只有使用DH算法才需要这些步骤
   • master_secret = PRF（pre_master_secret，“master secret”，ClientHello.random + ServerHello.random）[0..47];，master_secret会用来生成对称加密的秘钥和HMAC 4.TLS在client Hello和server Hello阶段会各自给对方传一个random number，并且计算master_secret的时候会使用这两个随机数，这是为了防止重放攻击(Replay Attacks)。假设中间人监听了client端发给server端的所有消息(包括建立TLS连接的消息和后面加密的数据消息)，虽然中间人无法对消息进行解密，但过了十分钟后，它可以将这些消息复制并重新发送给server端，server端对于重放攻击与前面的正常连接生成的pre_master_secret都是一样的，如果我们只是使用pre_master_secret来生成对称加密的秘钥的话，那么中间人在与server端建立连接后，可以继续发送之前监听到的加密过的数据消息，假设这些数据消息是在淘宝下单了一件东西，那么可能造成的影响就是同样的东西被下单多次。但是由于我们使用了ServerHello.random来生成的master_secret，所以每次建立的TLS连接都会产生不同的master_secret(由master_secre生成的对称秘钥也就会不同)，即使后面中间人发送了与之前相同的加密消息，也会因为对称秘钥不同被server拒绝(https://security.stackexchange.com/questions/218491/why-using-the-premaster-secret-directly-would-be-vulnerable-to-replay-attack)