计算机网络

重点学习内容

应用层
- WEB应用
  - Http连接类型
  - Http消息格式
  - Cookie技术
  - WEB缓存技术
传输层
- UDP
  - 可靠信道
  - 滑动窗口协议
- TCP
  - TCP超时重传机制
  - 流量控制
  - 三次握手四次挥手
  - 拥塞控制
  - TCP拥塞控制原理

一、计算机网络体系结构

1. OSI

应用层 ：为特定应用程序提供数据传输服务，例如 HTTP、DNS 等协议。数据单位为报文。
表示层 ：数据压缩、加密以及数据描述，这使得应用程序不必关心在各台主机中数据内部格式不同的问题。
会话层 ：建立及管理会话。
传输层 ：为进程提供通用数据传输服务。由于应用层协议很多，定义通用的传输层协议就可以支持不断增多的应用层协议。运输层包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。TCP 主要提供完整性服务，UDP 主要提供及时性服务。
网络层 ：为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。网络层把传输层传递下来的报文段或者用户数据报封装成分组。
数据链路层 ：网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。
物理层 ：考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异。

2. TCP/IP

它只有四层，相当于数据链路层和物理层合并为网络接口层。

TCP/IP 体系结构不严格遵循 OSI 分层概念，应用层可能会直接使用 IP 层或者网络接口层。

3. 五层协议

五层协议没有表示层和会话层，而是将这些功能留给应用程序开发者处理。

应用层 ：为特定应用程序提供数据传输服务，例如 HTTP、DNS 等协议。数据单位为报文。
传输层 ：为进程提供通用数据传输服务。由于应用层协议很多，定义通用的传输层协议就可以支持不断增多的应用层协议。运输层包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。TCP 主要提供完整性服务，UDP 主要提供及时性服务。
网络层 ：为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。网络层把传输层传递下来的报文段或者用户数据报封装成分组。
数据链路层 ：网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。
物理层 ：考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异。

[

4. 数据在各层之间的传递过程

在向下的过程中，需要添加下层协议所需要的首部或者尾部（进行的是分组交换），而在向上的过程中不断拆开首部和尾部。

路由器只有下面三层协议，因为路由器位于网络核心中，不需要为进程或者应用程序提供服务，因此也就不需要传输层和应用层。

二、应用层

2.1 域名系统

DNS 是一个分布式数据库，提供了主机名和 IP 地址之间相互转换的服务。这里的分布式数据库是指，每个站点只保留它自己的那部分数据。

域名具有层次结构，从上到下依次为：根域名、顶级域名、二级域名。

[

DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输，这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。在两种情况下会使用 TCP 进行传输：

如果返回的响应超过的 512 字节（UDP 最大只支持 512 字节的数据）。
区域传送（区域传送是主域名服务器向辅助域名服务器传送变化的那部分数据）。

2.2 常用端口

应用	应用层协议	端口号	传输层协议	备注
域名解析	DNS	53	UDP/TCP	长度超过 512 字节时使用 TCP
动态主机配置协议	DHCP	67/68	UDP
简单网络管理协议	SNMP	161/162	UDP
文件传送协议	FTP	20/21	TCP	控制连接 21，数据连接 20
远程终端协议	TELNET	23	TCP
超文本传送协议	HTTP	80	TCP
简单邮件传送协议	SMTP	25	TCP
邮件读取协议	POP3	110	TCP
网际报文存取协议	IMAP	143	TCP

2.3 WEB应用（重点）

Http协议是无状态协议（服务器不维护任何客户端过去所发请求信息）

2.3.1 Http连接类型

非持久连接（Http1.0）：每个TCP连接最多传输一个对象

持久连接（Http1.1）：每个TCP连接可以传输多个对象

2.3.2 Http消息格式

Http有两类消息：请求消息和响应消息

请求：

响应：

2.3.3 HTTP 请求页面

有了 HTTP 服务器的 IP 地址之后，主机就能够生成 TCP 套接字，该套接字将用于向 Web 服务器发送 HTTP GET 报文。
在生成 TCP 套接字之前，必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 80 的 TCP SYN 报文段，并向 HTTP 服务器发送该报文段。
HTTP 服务器收到该报文段之后，生成 TCP SYN ACK 报文段，发回给主机。
连接建立之后，浏览器生成 HTTP GET 报文，并交付给 HTTP 服务器。
HTTP 服务器从 TCP 套接字读取 HTTP GET 报文，生成一个 HTTP 响应报文，将 Web 页面内容放入报文主体中，发回给主机。
浏览器收到 HTTP 响应报文后，抽取出 Web 页面内容，之后进行渲染，显示 Web 页面。

2.3.4 Cookie技术

网站为了辨别用户身份、进行session跟踪而存储在用户本地的数据

Cookie组件：

请求中的cookie头部行
响应中的cookie头部行
保存在客户主机的cookie文件，由浏览器管理（清理垃圾时的那个）
Web服务器端的后台数据库（保存数据）

2.3.5 WEB缓存技术

流程：

用户设定浏览器通过web缓存进行web访问
浏览器向代理服务器发送http请求

a) 如果请求对象在缓存中，返回对象

b) 如果不在，缓存服务器向原始web服务器发送http请求，缓存保存并将请求对象返回给客户端

条件性GET方法：

Web缓存在Http请求中声明所持有的版本的信息

如果缓存所持有的版本是最新的，返回304，否则返回200+最新数据

三、传输层

3.1 UDP

优点：

无需建立连接（减少延迟）
实现简单
头部开销小
没有拥塞控制

在UDP上实现可靠数据传输:

在应用层增加可靠性机制
应用特定的错误恢复机制

3.1.1 可靠信道

Rdt1.0完全可靠信道（不切实际的）

Rdt2.0（符合实际的某一种信道，产生位错误的信道）：

解决位错误：ARQ协议，利用校验和检测位错误

正确发送ACK，错误发送NAK，所以当发送方收到NAK后，重传分组。

Rdt2.1若ACK/NAK坏掉：

发送方重传分组。（发送方给每个分组增加序列号，接收方丢弃重复分组）

Rdt2.2改进：只使用ACK：

通过ACK告知最后一个被正确接收的分组。发送方收到重复序列号的ACK，视为NAK。（例如0正确接收，1没有正确接收，则返回0的ACK，跟上次返回重复（上次0成功也是返回0），所以判定是NAK）

Rdt3.0解决丢失分组：

发送方等待合理时间（需要一个定时器），未收到ACK，重传

总结：构建可靠信道：

发送方发送一个分组，附带序列号
接收方根据检验和检验接收的分组是否正确。若正确，发送ACK+当前序列号；若错误，发送ACK+上一序列号
发送方若收到ACK，则准备传输ACK序列号+1的分组。若在合理等待时间内未收到ACK或ACK被损坏，则重传上一分组。

3.1.2 滑动窗口协议

同时可以传输等待多个分组（前面都是一个个的发，单个分组），减少RTT（往返时间）对网络吞吐量的影响。

GBN：连续发生多个分组，累计确认

接收方只同时等待一个分组。乱序到达的分组直接丢弃。

累计确认：每个ACK可确认多个分组（即ACK(N)确认该ACK N序号之前的所有分组）。

1、如果未收到（即图中pkt2），后序发送的分组就会一直返回最高序列号的ACK（即图中的ACK1）

2、后序发送的分组还会重新发送一遍（即pkt2~pkt5都会重传一遍）

SR：连续发生多个分组，不采用累积确认，缓存乱序的分组

每个ACK确认一个分组，不累积确认

接收方需缓存乱序到达的分组，最后正序到达后一起连同缓存的一起发

3.3 TCP

TCP采用流水线机制、ACK累计确认（按序到达的最后一个分组发送确认）机制，对于乱序分组的处理没有作规范。

TCP序列号是传输的第一个字节的序列号。

3.2.1TCP超时重传机制

触发重传的事件：超时、收到重复ACK，只会重传超时的段（类似SR）

设置定时器超时时间：测量多个RTT，求平均值ERTT，同时ERTT不断修正。

定时器超时时间=ERTT+安全边界（ERTT变化越大，边界越大）

快速重传机制：在超时之前进行重传

如果触发重传，会导致超时时间加倍。为减小重传延迟，发送方连续收到3个相同序列号ACK即立刻重传。

3.2.2流量控制

原因：Buffer溢出，防止发送方传输太多太快，以至淹没接收方。

做法：

接收方在段头部将剩余空间告诉发送方，
发送方限制已发送但未ACK的大小不超过接收方剩余空闲空间。

3.2.3 三次握手四次挥手

三次握手：

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

四次挥手：

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

总结：

客户端向服务端发送FIN报文段。头部FIN位置1。
服务端返回一个ACK。
服务端发送一个FIN。
客户端返回一个ACK。

3.2.4 拥塞控制

定义：不要让中间网络传输处理不了，区别于流量控制

拥塞控制的方法：

端到端拥塞控制（TCP采用）：网络层不需要提供支持；

端系统host通过观察loss和delay等判断是否发生了拥塞。
网络辅助的拥塞控制：路由器向发送方显式的反馈网络拥塞，指示发送方应采取何种速率发送。（最近的tcpip也可选择性实现该方法）

a) 直接网络反馈：发生拥塞的路由器直接向发送方反馈

b) 经由接收方的网络反馈：发送方发出一个测试分组至接收方，接收方再传回。途中经过拥塞路由器，标记拥塞。

3.2.5 TCP拥塞控制原理

限制发送流量的速率
感知路径上存在拥塞
感知到拥塞后使用何种算法降低速率？
拥塞窗口：类似于流量控制的接收窗口。

已发送但未ACK的分组数 < min(拥塞窗口, 接收窗口)

丢失意味着拥塞，收到ACK意味着可以增加速率。
慢启动；加性增乘性减

启动时初始速率极低，但拥塞窗口指数增长。
达到Threshold（loss时间发生前的拥塞值的一半）时，变为线性增长。
当出现loss时：

出现三个重复ACK，拥塞窗口大小减半 + 3（3个ack）。
出现timeout时，代表网络拥堵极为严重，拥塞窗口回归初始值1。Threshold设置为当前拥塞窗口大小的1/2。（早期版本tcp无快速恢复，出现loss即回归初始值）

四、面试问题（重重重重点！！！！）

4.1 各层的结构与功能,都有哪些协议

应用层

应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。

域名系统DNS：它作为可以将域名和IP地址相互映射的一个分布式数据库
HTTP协议：超文本传输协议
传输层

传输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。

应用进程利用该服务传送应用层报文，多种应用可以通过复用和分用使用同一个运输层服务。

TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务。
UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。
网络层

在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点，确保数据及时传送。

数据链路层

数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

物理层

物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，使其上面的数据链路层不必考虑网络的具体传输介质是什么。

4.2 TCP三次握手与四次挥手（面试常客）

4.2.1 为什么要三次握手

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

4.2.2 为什么要四次挥手

客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
服务器-收到这个 FIN，它发回一个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
服务器-关闭与客户端的连接，发送一个FIN给客户端
客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

4.2.3 拓展

为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

为什么不能用两次握手进行连接？

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

为什么要传回 SYN

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。

SYN 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement[汉译：确认字符 ,在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。 ]）消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。

传了 SYN,为啥还要传 ACK

双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

TCP四次挥手

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

4.3 TCP,UDP 协议的区别

TCP、UDP协议的区别

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

4.4 在浏览器中输入url地址 ->> 显示主页的过程(面试常客)

打开一个网页，整个过程会使用哪些协议，总体来说分为以下几个过程:

DNS解析
TCP连接
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
连接结束

4.5 HTTP长连接,短连接

总结：