计算机网络基础知识

概述

1. 电路交换的步骤

• 建立连接

• 通话：一直占用通信资源

• 释放连接：归还通信资源

2. 带宽

通道传送数据的能力，单位是bit/s

3. 时延

• 发送时延：

• 处理时延：主机或者路由器收到分组时花费一定的时间进行处理，如分析首部，从分组中提取数据部分，进行差错检测或者查找适合路由等。

• 传播时延

• 排队时延：输入队列和输出队列

4. 有效数据率和利用率

• 数据长度/(发送时间+RTT)

• 信道利用率不是越高越好，利用率过高会产生非常大的时延。

5. 网络协议三要素：

为进行网络中的数据交换而建立的规则，标准协议或者约定称为网络协议。

• 语法：数据与控制信息的结构或格式

• 语义：发出何种控制信息，完成何种动作

• 同步：事件实现顺序的详细说明

6. OSI七层协议：

应用层，表示层，会话层，运输层，网络层，数据链路层，物理层

7. 五层协议：

OSI七层协议，TCP/IP四层协议

• 应用层（application layer）：通过应用进程间的交互完成特定的网络应用

• 运输层（transport layer）：**两台主机进程之间的通信提供通用的数据传输服务。**复用和分用

• 网络层（network layer）：为分组交换网的主机提供通信服务。为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。网络层把传输层传递下来的报文段或者用户数据报封装成分组。

• 数据链路层（data link layer）：将源计算机网络层来的数据可靠地传输到相邻节点的目标计算机的网络层。将IP数据报组装成帧。网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。

• 物理层（physical layer）：数据单位为bit。多大的电压代码1和0，以及接收方如何识别发送方发出的比特。考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异。

  

8. 分层的好处

• 分层：可以将庞大而复杂的问题转化为若干个较小的局部问题，而这些局部的问题易于研究和处理。

• 各层之间是独立的：一层不需要知道它下一层如何实现，只需要知道改层通过层间接口所提供的服务。每层实现一种相对独立的功能。

• 灵活性好：当任何一层发生变化时，只要层间接口关系保持不变，则改层以上或者以下的各层均不受影响。

• 结构上可分割：各层可以采用最合适的技术来实现。

• 易于实现和维护：系统被分解为若干个相对独立的子系统。结构化。

• 能促进标准化工作：

物理层

1. 定义及任务：

如何在传输媒介上传输数据比特流，而不是具体的传输媒介。==物理层的真正作用正是尽可能地屏蔽掉这些传输媒体和通信手段的差异，使得物理层上面的数据链路层感觉不到这些差异，这样就可以使得数据链路层只考虑完成本层的协议和服务，而不必考虑网络的具体传输媒体和通信手段。

2. 主要任务：

确定与传输媒体的接口有关的一些特性。

• 机械特性

• 电气特性：电压的范围

• 功能特性：电压的意义

• 过程特性

3. 信道相关

• 信道的带宽或者信道中的信噪比越大，信息的极限传输速率越高。

• 每一个码元携带更多比特的信息量，可以间接提高信息的传输速率。

• 香农公式：只要信息传输速率低于信道的极限信息传输速率，就一定存在一种方法来实现无差错传输。

4. 信道复用技术

• 频分复用：同时间占用不同的带宽资源

• 时分复用：在不同的时间占用相同的带宽

• 统计时分复用：

• 波分复用

• 码分复用：码分多址CDMA，码片序列，内积

5. 宽带接入技术

• 有线宽带接入

• • ADSL技术：调制解调器，使得数字信号的频谱适合在原来用户线传输。
• • 光纤同轴混合网：电缆调制解调器，客户端。
• • 光纤到户：

• 无限宽带接入

数据链路层

**作用：**为了使数据在相邻结点间的链路上传输，数据链路层将网络层交下来的IP数据报组装成帧，每个帧有控制信息。

1. 协议

点对点协议PPP，CSMA/CD协议

• 多点接入：总线型网络，同一时间只允许一台计算机发送数据

• 载波监听：不停检测信道

• 碰撞检测：边发送边检测

2. 截断二进制指数退避：r倍的争用期（2τ）

• 经过争用期这段时间还没有检测到碰撞，才能肯定这次发送不会发生碰撞。

• 以太网规定了最短帧为64字节即512bit。

• 帧间最小间隔：9.6μs--->为了使得刚刚收到数据帧的站的接收缓存来得及清理，做好接收下一个帧的准备。

3. 三个基本问题：

• 封装成帧：首部和尾部，数据部分最大传送单元MTU。SOH和EOT

• 透明传输：帧定界控制符，字节填充：在数据部分出现的控制字符前插入转义字符ESC。

• 差错检测：比特差错，误码率，循环冗余检验CRC：n位冗余码。

4. 可靠传输与无比特差错的传输（传输差错和比特差错）

• 可靠传输：数据链路层的发送端发送什么，在接收端就接收什么。

• 传输差错：包括比特差错和复杂的传输差错

• 帧丢失

• 帧重复

• 帧失序

5. CSMA/CD 协议

CSMA/CD 表示载波监听多点接入 / 碰撞检测。

• 多点接入 ：说明这是总线型网络，许多主机以多点的方式连接到总线上。

• 载波监听 ：每个主机都必须不停地监听信道。在发送前，如果监听到信道正在使用，就必须等待。

• 碰撞检测 ：在发送中，如果监听到信道已有其它主机正在发送数据，就表示发生了碰撞。虽然每个主机在发送数据之前都已经监听到信道为空闲，但是由于电磁波的传播时延的存在，还是有可能会发生碰撞。

记端到端的传播时延为 τ，最先发送的站点最多经过 2τ 就可以知道是否发生了碰撞，称 2τ 为 争用期 。只有经过争用期之后还没有检测到碰撞，才能肯定这次发送不会发生碰撞。

当发生碰撞时，站点要停止发送，等待一段时间再发送。这个时间采用 截断二进制指数退避算法 来确定。从离散的整数集合 {0, 1, .., (2k-1)} 中随机取出一个数，记作 r，然后取 r 倍的争用期作为重传等待时间。

6. PPP点对点协议：

用户计算机与ISP进行通信时所使用的数据链路层协议。

• LCP+NCP：链路控制协议和网际控制协议

• 字节填充：

• 零比特填充：5个连续1就插入一个0

7. 共享通信媒体资源

• 静态划分信道：复用

• 动态媒体接入控制：多点接入。

  • 随机接入：需要解决碰撞

  • 受控接入：服从一定控制，轮询

8. 适配器的作用：

• 串行传输和并行传输的转换：适配器与局域网之间的通信以串行的方式进行，而适配器和计算机之间的通信则是通过I/O总线以并行方式进行的。

• 对数据进行缓存：网络数据率和总线数据率并不相同。

• 实现以太网协议：

9. 6字节MAC地址

固化在网络适配器上的地址：一台主机拥有多少个网络适配器就有多少个 MAC 地址。例如笔记本电脑普遍存在无线网络适配器和有线网络适配器，因此就有两个 MAC 地址。

适配器的过滤功能：根据MAC帧中的目的地址判断

• 单播帧

• 广播帧

• 多播帧

10. 已经有IP地址，为什么还要使用MAC地址？

简单的说一台电脑上的ip地址是会变化的，随着时间和不同的网络环境都会不一样，mac地址是物理地址在这台电脑上面的固定不会变化的。

那么为什么我们需要IP地址呢？因为如果我们只用MAC地址的话，我们会发现路由器需要记住每个MAC地址所在的子网是哪一个（不然每一次收到数据包的时候路由器都要重新满世界地去找这个MAC地址的位置）。而世界上有2^48个MAC地址，这就意味着即使我们给每个MAC地址只留1字节的储存空间，每个路由器也需要256TB的内存！这显然是不可能实现的

这就是我们需要IP地址的原因了。和MAC不同的是，IP地址是和地域相关的。对于位于同一个子网上的设备，我们给他们分配的IP地址前缀都是一样的。这个前缀就像邮政编码一样。这样，路由器通过IP地址的前缀就能知道这个设备在哪个子网上了。现在，路由器只需要记住每个子网的位置即可，大大减少了路由器所需要的内存

既然IP地址不能去掉，那么能不能去掉MAC地址呢？也不能。因为IP地址是要设备上线以后才能根据他进入了哪个子网来分配的，在设备还没有IP地址的时候（或者分配IP地址的过程中），我们还需要用MAC地址来区分不同的设备

11. 无效的帧

MAC帧的格式：目的地址+原地址+类型+数据（IP数据报，长度为46-1500）+FCS

• 帧的长度不是整数个字节

• 用收到的帧检测序列FCS查出有差错

• 收到的帧的MAC客户数据字段的长度不在46-1500字节之间。

12. 在数据链路层扩展以太网：使用网桥和以太网交换机

• 以太网交换机的自学习能力：MAC地址+接口。

• 总线以太网和星型以太网

  总线以太网使用CSMA/CD协议，以半双工的方式工作。但是以太网交换机不使用共享的总线，没有碰撞问题，因此不使用CSMA/CD协议，而是以全双工的方式工作。

13. 虚拟局域网

• VLAN：virtual local area network

• **与物理地址无关的逻辑组的一些局域网网段。**IEEE 定义了一种扩展的以太网帧格式 802.1Q，它在标准以太网帧上加进了 4 字节首部 VLAN 标签，用于表示该帧属于哪一个虚拟局域网。

• 广播风暴：以太网交换机不会向虚拟局域网以外的主机传送计算机的广播信息。

• 划分vlan的作用：

  • 隔离广播域，让每个节点不需要收到太多无关的广播包，从而减少计算性能和网络带宽的无畏消耗，从而保证局域网的性能。

  • 隔离常见病毒和攻击，这样即使某个主机感染了arp攻击病毒，dhcp攻击病毒等常见局域网病毒，影响的范围也只在本vlan中，不会影响其他vlan，故可以将故障限制在较小的范围内。一来造成的影响小，而来排查故障更加容易。

网络层

网络层向上只提供简单灵活的，无连接的，尽最大努力交付的数据报服务。

1. 常见的协议：

1.1 IP协议：网际协议IP

• 

1.2 ARP协议（地址解析协议）：本局域网，根据IP地址找硬件地址。

ARP高速缓存：映射表

ARP是地址解析协议，简单语言解释一下工作原理。

1. 首先，每个主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的映射

2. 当源主机要发送数据时，首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址，如果有，则直接发送数据，如果没有，就向本网段的所有主机发送ARP数据包，该数据包包括的内容有：源主机IP地址，源主机MAC地址，目的主机的IP地址。

3. 当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中，如果已经存在，则覆盖，然后将自己的MAC地址写入ARP响应包中，告诉源主机自己是它想要找的MAC地址。

4. 源主机收到ARP响应包后。将目的主机的IP和MAC地址写入ARP列表，并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

广播发送ARP请求，单播发送ARP响应。

1.3 ICMP协议（网际控制报文协议）：

ICMP 是为了更有效地转发 IP 数据报和提高交付成功的机会。它封装在 IP 数据报中，但是不属于高层协议。

允许主机或者路由器报告差错情况以及提供有关异常情况的报告。（ICMP报文装在IP数据报中）。ping命令和traceroute命令

差错报告报文：终点不可达，时间超时，参数问题，改变路由（重定向）

询问报文：回送请求和回答，时间戳请求和回答

不应发送ICMP差错报告报文的情况

• 对ICMP差错报文，不再发送ICMP差错报告报文

• 对第一个分片的数据报片的所有后续数据报片，都不发送ICMP差错报告报文。

• 对具有多播地址的数据报，都不发送ICMP差错报告报文

• 对具有特殊地址如127.0.0.0和0.0.0.0的数据报，不发送ICMP差错报告报文

1.4 IGMP（网际组管理协议）：

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

1.5 路由选择协议：得出路由表中的路由

1.5.1 内部网关协议RIP：距离向量法。（注意报文：使用运输层的UDP进行传送）

RIP 是一种基于距离向量的路由选择协议。距离是指跳数，直接相连的路由器跳数为 1。跳数最多为 15，超过 15 表示不可达。

RIP 按固定的时间间隔仅和相邻路由器交换自己的路由表，经过若干次交换之后，所有路由器最终会知道到达本自治系统中任何一个网络的最短距离和下一跳路由器地址。

到目的网络n+距离是d+下一跳路由器是X

问题：坏消息传播很慢

距离向量算法：

• 对地址为 X 的相邻路由器发来的 RIP 报文，先修改报文中的所有项目，把下一跳字段中的地址改为 X，并把所有的距离字段加 1；

• 对修改后的 RIP 报文中的每一个项目，进行以下步骤：

• 若原来的路由表中没有目的网络 N，则把该项目添加到路由表中；

• 否则：若下一跳路由器地址是 X，则把收到的项目替换原来路由表中的项目；否则：若收到的项目中的距离 d 小于路由表中的距离，则进行更新（例如原始路由表项为 Net2, 5, P，新表项为 Net2, 4, X，则更新）；否则什么也不做。

• 若 3 分钟还没有收到相邻路由器的更新路由表，则把该相邻路由器标为不可达，即把距离置为 16。

1.5.2 内部网关协议OSPF：

链路状态协议，开放最短路径优先。（直接使用IP数据报进行传送）

开放表示 OSPF 不受某一家厂商控制，而是公开发表的；最短路径优先表示使用了 Dijkstra 提出的最短路径算法 SPF。

更新过程收敛得很快

OSPF 具有以下特点：

• 向本自治系统中的所有路由器发送信息，这种方法是洪泛法。

• 发送的信息就是与相邻路由器的链路状态，链路状态包括与哪些路由器相连以及链路的度量，度量用费用、距离、时延、带宽等来表示。

• 只有当链路状态发生变化时，路由器才会发送信息。

1.5.3 外部网关协议BGP：

路径向量路由选择协议。要建立TCP连接。

BGP（Border Gateway Protocol，边界网关协议）

AS 之间的路由选择很困难，主要是由于：

• 互联网规模很大；

• 各个 AS 内部使用不同的路由选择协议，无法准确定义路径的度量；

• AS 之间的路由选择必须考虑有关的策略，比如有些 AS 不愿意让其它 AS 经过。

BGP 只能寻找一条比较好的路由，而不是最佳路由。

2. 有哪些私有（保留）地址？

• A类：10.0.0.0 - 10.255.255.255

• B类：172.16.0.0 - 172.31.255.255

• C类：192.168.0.0 - 192.168.255.255

3. 分类的IP地址：网络号+主机号，点分十进制记法

• A类网络：8位网络号（0。。。）+24位主机号。网络号：1-126。最多可指派的网络数：2^7-2。127表示环回测试。

• B类网络：16位网络号（10。。。）+16位主机号。网络号：128.1-191.255。最多可指派的网络数：2^14-1。128.0.0.0一般不指派

• C类网络：24位网络号（110。。。）+8位主机号。网络号：192.0.1-233.255.255。最多可指派的网络数：2^21-1。192.0.0.0一般也不指派

• D类网络：（1110。。。）

4. 划分子网：网络号+子网号+主机号

子网掩码好处：不管网络有没有划分子网，只要将子网掩码和IP地址进行逐位与运算即可立即得出网络地址。

使用子网时分组转发：目的网络地址，子网掩码，下一跳地址

5. 构造超网：无分类域间路由选择

• 路由聚合：CIDR把网络前缀都相同的连续的IP地址组成一个CIDR地址块。

• 网络前缀：用于指明网络。

• 无分类编址CIDR：斜线记法

6. 路由器的结构

• 路由选择部分：构造路由表，维护和更新路由表

• 分组转发部分：交换结构，输入端口，输出端口

7. VPN

• 本地地址和全球地址

• 由于 IP 地址的紧缺，一个机构能申请到的 IP 地址数往往远小于本机构所拥有的主机数。并且一个机构并不需要把所有的主机接入到外部的互联网中，机构内的计算机可以使用仅在本机构有效的 IP 地址（专用地址）。

• 有三个专用地址块：

  • 10.0.0.0 ~ 10.255.255.255

  • 172.16.0.0 ~ 172.31.255.255

  • 192.168.0.0 ~ 192.168.255.255

8. NAT网络地址转换

使用专用地址的主机和互联网上的主机通信

9. IPv6和IPv4的异同

• IPv6：基本首部（40字节）+有效载荷（多个扩展首部+数据部分），IPv4：首部（固定部分（20字节）+可变部分）+数据部分

• IPv6的地址从IPv4的32位增加到128位，这样大的地址空间在可预见的未来无法使用完。

• IPv4采用点分十进制方法，IPv6采用冒号十六进制记法。

• IPv4的首部是可变的，后者的首部是固定的40字节。

• IPv6允许协议继续扩充，但是IPv4的功能是不变的。

• 相同点：都具有原地址和目的地址，只不过位数不同，32位和128位

IPv4向IPv6过渡：

• 双协议栈：使一部分主机装有双协议栈，既可以和IPv4的系统通信，又可以和IPv6的系统通信。具有两种地址。

• 隧道技术：二次封装技术，IPv6数据报被封装成IPv4数据报。

运输层

1. 请简述TCP/UDP的区别

TCP和UDP是OSI模型中的运输层中的协议。TCP提供可靠的通信传输，而UDP则常被用于让广播和细节控制交给应用的通信传输。

• TCP面向连接，UDP面向无连接即发送数据前不需要建立链接

• TCP提供可靠的服务（数据传输），UDP无法保证

• TCP面向字节流，UDP面向报文

• TCP数据传输慢，UDP数据传输快

TCP和UDP的区别与联系

1. TCP面向连接，传输数据之前要需要建立会话。UDP是无连接的。

2. TCP提供可靠传输，保证数据不丢包、不重复且按顺序到达；UDP只尽努力交付，不保证可靠交付

3. TCP提供了拥塞控制；UDP不提供

4. TCP是面向字节流的；UDP面向报文。

5. TCP只支持点到点通信；UDP支持一对一、一对多、多对多的交互通信。

6. TCP首部开销大20字节，UDP首部开销小8字节。

UDP用户数据报和IP数据报：两者都是面向无连接的，提供尽最大努力的交互的服务。

常见的端口及对应的服务？

**此外，上图中使用TCP协议的应用或者服务有电子邮件（SMTP协议），TELNET协议（远程终端接入），HTTP协议，FTP协议（文件传送协议）。**其他的都是使用UDP协议。

端口号

• 服务器端使用的端口号

  • 熟知端口号：0-1023

  • 登记端口号：1024-49151

• 客户端使用的端口号

  • 49152-65535

2. TCP对应的应用层协议

• FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。

• Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。

• SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。

• POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。

• HTTP：从Web服务器传输超文本到本地浏览器的传送协议。

3. UDP对应的应用层协议

• DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。

• SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

• TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

4. UDP的报文格式

5. 可靠传输的工作原理

当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时及时告知发送方适当降低发送数据的速度。

5.1 停止等待协议

• 每发送一个分组就停止发送，等待对方确认。

• 超时重传：出现差错，超时计时器

• 确认丢失和确认迟到

  • 确认丢失 ：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。

  • 确认迟到 ：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。

• 优点： 简单

• 缺点： 信道利用率低，等待时间长

5.2 连续ARQ协议

• 发送方每次收到一个确认，就把发送窗口向前滑动一个分组的位置。

• 但是接收方一般采用累积确认的方式，即接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认。

• 优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。

• 缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

6. TCP报文段格式

• 序号

• 确认号：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。

• 确认ACK：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。

• 同步SYN：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。

• 终止FIN：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。

• 窗口：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。

7. TCP可靠传输的实现

1. 以字节为单位的滑动窗口

2. 超时重传时间的选择

3. 选择确认SACK

8. TCP流量控制

• 让发送方发送速率不要太快，要让接收方来得及接收。

• 使用滑动窗口实现流量控制: 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

• 流量控制是指点对点通信量的控制，是一个端到端的问题。

9. 拥塞控制及TCP的拥塞控制的方法

• 防止大量的数据注入到网络中，可以使网络中的路由器或者链路不会过载。

• 如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

9.1 慢开始

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。 慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。实时拥塞窗口大小是以字节为单位的。当然收到单个确认但此确认多个数据报的时候就加相应的数值。所以一次传输轮次之后拥塞窗口就加倍。这就是乘法增长，和后面的拥塞避免算法的加法增长比较。 为了防止cwnd 增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh 状态变 量。ssthresh 的用法如下：

• 当cwnd<ssthresh 时，使用慢开始算法。

• 当cwnd>ssthresh 时，改用拥塞避免算法。

• 当cwnd=ssthresh 时，慢开始与拥塞避免算法任意。

9.2 拥塞避免

拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT 就把发送方的拥塞窗口cwnd 加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。 无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限ssthresh 设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。

9.3 快重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

9.4 快恢复

① 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh 门限减为当前拥塞窗口的一半。但是接下去并不执行慢开始算法。

② 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd 设置为ssthresh 的大小，然后执行拥塞避免算法。

TCP 的三次握手

假设 A 为客户端，B 为服务器端。

• 首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。

• A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。

• B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。

• A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。

• B 收到 A 的确认后，连接建立。

三次握手的原因

第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

TCP 的四次挥手

以下描述不讨论序号和确认号，因为序号和确认号的规则比较简单。并且不讨论 ACK，因为 ACK 在连接建立之后都为 1。

• A 发送连接释放报文，FIN=1。

• B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。

• 当 B 不再需要连接时，发送连接释放报文，FIN=1。

• A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。

• B 收到 A 的确认后释放连接。

四次挥手的原因

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

TIME_WAIT

客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

• 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。

• 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

10. 三次握手相关问题：

• 为什么要三次握手？

  • 第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

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

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常 第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了： 自己接收正常，对方发送正常 第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了： 自己发送、接收正常，对方发送、接收正常 所以三次握手就能确认双发收发功能都正常，缺一不可。

• 传了 SYN,为啥还要传 ACK？

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

• **为什么客户端最后还要发送一次确认呢？**即为什么不能只两次握手？

防止已经失效的连接请求报文段突然又传送到了B。如果没有第三次握手，只要B发出了确认连接报文段，新的连接就建立了。但是由于现在A没有发出建立连接的请求，因此不会理理睬B的确认，也不会向B发送数据。但B却认为新的连接已经建立了，并且一直等待A发送来的数据。B的资源也就浪费了。

• 为什么不需要四次握手？

1. A发送同步信号SYN+ A's Initial sequence number
2. B确认收到A的同步信号，并记录 As ISN到本地，命名B' s ACK sequence number
3. B发送同步信号sYN+B' s Initial sequence number
4. A确认收到B的同步信号，并记录Bs|SN到本地，命名 A's ACK sequence number
5. 很显然2和3这两个步骤可以合并，只需要三次握手，可以提高连接的速度与效率。

11. 四次挥手相关问题：

• 为什么释放连接需要四次挥手，而请求连接只需要三次握手？

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

  • 客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

• 为什么A在TIME-WAIT状态必须等待2MSL的时间？时间等待计时器

  • 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

  • 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

• **如果已经建立了连接，但是客户端突然出现故障了怎么办？**服务器端设置保活计时器。

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

12. 粘包问题及其解决方案

拆包粘包产生的原因

图一是正常的情况下包的发送和接受，客户端发送p1，p2包，服务端先后接受到p1，p2包，没有发生粘包和拆包。

图二是发生了拆包的现象。客户端发送p1，p2包，客户端对p1拆包分成p1_1和p1_2，服务端先后收到p1_1，p1_2和p2包。 拆包发生原因分2种情况：

1. 发送的数据大于套接字缓冲区剩余大小。

2. 发送的数据大于MTU(最大传输单元)大小。

在TCP通讯协议中TCP的每个包的头的长度都是固定的，总长度不能超过MTU(最大传输单元)，且数据长度不能超过MSS(MSS=MTU-20bytes(IP包头)-20bytes(TCP包头))。如果超过了MTU系统会进行拆包处理。以图二举个例子：

• 假设MTU设置的长度为1500bytes则MSS为1460bytes。

• 客户端发送了p1包数据大小2000bytes。

• 系统判断总长度超过了MTU大小，需要拆包处理。

• 拆成2个包p1_1和p1_2，p1_1的总长度=1460+20+20=1500，p1_2的总长度=2000-1460+20+20=580。

• 发送包p1_1和包p1_2。

图三是发生了粘包的现象。客户端发送p1，p2包，p1，p2包到达接收端的缓存，服务端应用读取缓存时无法区分p1，p2各自的大小。因为在TCP通讯协议中TCP是面向流的，包和包之间没有界限。粘包可发生在发送端也可发生在接收端以图三各举例子：

• 发送端原因导致的粘包，客户端在发送p1包时，先将p1包放入发送缓存，由于Nagle算法判断其发送的可用数据（去头数据）过小等待一小段时间，这时又发送了p2包，系统将p1和p2合成一个大包发送给服务端。服务端读到大包，无法区分p1和p2包。

• 接收端原因导致的粘包，服务端缓存接收到客户端发送的p1包，服务端应用未能及时读取缓存，此时服务端缓存又接收到客户端发送的p2包，服务端应用读取缓存，无法区分p1和p2包。

解决方案

无论拆包还是粘包本质问题都是无法区分包界限，解决包界限的问题主要有以下几种方式：

1. 消息数据的定长，比如定长100字节，不足补空格，接收方收到后解析100字节数据即为完整数据。但这样的做的缺点是浪费了部分存储空间和带宽。

2. 消息数据使用特定分割符区分界限，比如使用换号符号做分割。

3. 把消息数据分成消息头和消息体，消息头带消息的长度，接收方收到后根据消息头中的长度解析数据。

应用层

1. 在浏览器中输入网址之后执行会发生什么？

1. 第一步：通过访问的域名找出其IP地址.（即域名解析）

DNS查找过程如下：

• 浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存各自固定的一个时间（2分钟到30分钟不等）。

• 操作系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。

• 本地hosts文件 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存。

• ISP DNS 缓存（本地域名服务器） – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。

• 若缓存没有，则递归搜索（根域名服务器） – 你的ISP的DNS服务器从跟域名服务器开始进行递归搜索，从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。

2. 建立TCP连接（三次握手）

3. 客户端发送http请求报文

（1）应用层：客户端发送HTTP请求报文。（HTTP协议）

（2）传输层：切分长数据，并确保可靠性。（tcp协议）

（3）网络层：进行路由 （ip协议、路由选择使用OSPF协议）

（4）数据链路层：传输数据（将ip地址转换为MAC地址，用ARP协议）

（5）物理层：物理传输bit

4. 服务器端经过物理层→数据链路层→网络层→传输层→应用层，解析请求报文，发送HTTP响应报文。

5. 关闭TCP连接

6. 浏览器解析HTML、布局显示，展示给用户

总体来说分为以下几个过程:

1. DNS解析

2. TCP连接

3. 发送HTTP请求

4. 服务器处理请求并返回HTTP报文

5. 浏览器解析渲染页面

6. 连接结束

2. Web页面请求过程

2.1. DHCP配置主机信息

• 假设主机最开始没有 IP 地址以及其它信息，那么就需要先使用 DHCP 来获取。

• 主机生成一个 DHCP 请求报文，并将这个报文放入具有目的端口 67 和源端口 68 的 UDP 报文段中。

• 该报文段则被放入在一个具有广播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 数据报中。

• 该数据报则被放置在 MAC 帧中，该帧具有目的地址 FF:FF:FF:FF:FF:FF，将广播到与交换机连接的所有设备。

• 连接在交换机的 DHCP 服务器收到广播帧之后，不断地向上分解得到 IP 数据报、UDP 报文段、DHCP 请求报文，之后生成 DHCP ACK 报文，该报文包含以下信息：IP 地址、DNS 服务器的 IP 地址、默认网关路由器的 IP 地址和子网掩码。该报文被放入 UDP 报文段中，UDP 报文段有被放入 IP 数据报中，最后放入 MAC 帧中。

• 该帧的目的地址是请求主机的 MAC 地址，因为交换机具有自学习能力，之前主机发送了广播帧之后就记录了 MAC 地址到其转发接口的交换表项，因此现在交换机就可以直接知道应该向哪个接口发送该帧。

• 主机收到该帧后，不断分解得到 DHCP 报文。之后就配置它的 IP 地址、子网掩码和 DNS 服务器的 IP 地址，并在其 IP 转发表中安装默认网关。

2.2. ARP解析MAC地址

• 主机通过浏览器生成一个 TCP 套接字，套接字向 HTTP 服务器发送 HTTP 请求。为了生成该套接字，主机需要知道网站的域名对应的 IP 地址。

• 主机生成一个 DNS 查询报文，该报文具有 53 号端口，因为 DNS 服务器的端口号是 53。

• 该 DNS 查询报文被放入目的地址为 DNS 服务器 IP 地址的 IP 数据报中。

• 该 IP 数据报被放入一个以太网帧中，该帧将发送到网关路由器。

• DHCP 过程只知道网关路由器的 IP 地址，为了获取网关路由器的 MAC 地址，需要使用 ARP 协议。

• 主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文，将该 ARP 查询报文放入一个具有广播目的地址（FF:FF:FF:FF:FF:FF）的以太网帧中，并向交换机发送该以太网帧，交换机将该帧转发给所有的连接设备，包括网关路由器。

• 网关路由器接收到该帧后，不断向上分解得到 ARP 报文，发现其中的 IP 地址与其接口的 IP 地址匹配，因此就发送一个 ARP 回答报文，包含了它的 MAC 地址，发回给主机。

2.3. DNS 解析域名

• 知道了网关路由器的 MAC 地址之后，就可以继续 DNS 的解析过程了。

• 网关路由器接收到包含 DNS 查询报文的以太网帧后，抽取出 IP 数据报，并根据转发表决定该 IP 数据报应该转发的路由器。

• 因为路由器具有内部网关协议（RIP、OSPF）和外部网关协议（BGP）这两种路由选择协议，因此路由表中已经配置了网关路由器到达 DNS 服务器的路由表项。

• 到达 DNS 服务器之后，DNS 服务器抽取出 DNS 查询报文，并在 DNS 数据库中查找待解析的域名。

• 找到 DNS 记录之后，发送 DNS 回答报文，将该回答报文放入 UDP 报文段中，然后放入 IP 数据报中，通过路由器反向转发回网关路由器，并经过以太网交换机到达主机。

2.4. 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 页面。

3. HTTP 协议包括哪些请求？

• GET：对服务器资源的简单请求

• POST：用于发送包含用户提交数据的请求（POST 请求是可以有体的，而GET 请求不能有请求体。）在服务器新建资源。

• HEAD：类似于GET请求，不过返回的响应中没有具体内容，用于获取报头

• PUT：传说中请求文档的一个版本，在服务器更新资源

• DELETE：发出一个删除指定文档的请求

• TRACE：发送一个请求副本，以跟踪其处理进程

• OPTIONS：返回所有可用的方法，检查服务器支持哪些方法

• CONNECT：用于ssl隧道的基于代理的请求

4. GET 和POST 请求的区别？

幂等意味着对同一URL 的多个请求应该返回同样的结果。

1. 前者将请求参数放在URL 中，文本格式；后者将请求参数放在请求体中，可以是文本、二进制等格式

2. 前者语义上是从服务器获取资源，安全（无副作用）、幂等、可缓存；后者语义上是向服务器提交资源，不安全（有副作用）、不幂等、不可缓存

3. 前者的URL 是明文传输，会保存在浏览器历史记录中，安全性不足，可能会受到CSRF攻击；后者较为安全（但是如果没有加密的话，都是可以明文获取的）

5. 响应码

响应头对浏览器来说很重要，它说明了响应的真正含义。例如200 表示响应成功了，302表示重定向，这说明浏览器需要再发一个新的请求。 2xx 表示成功，3xx 表示重定向，4xx 表示客户端出错，5xx 表示服务器出错。

• 200：请求成功，浏览器会把响应体内容（通常是html）显示在浏览器中；

• 404：请求的资源没有找到，说明客户端错误的请求了不存在的资源；

• 500：请求资源找到了，但服务器内部出现了错误；

• 302：重定向，当响应码为302 时，表示服务器要求浏览器重新再发一个请求，服务器会发送一个响应头Location，它指定了新请求的URL 地址；

• 304：（缓存）‘

1xx（临时响应） 表示临时响应并需要请求者继续执行操作的状态码。

100（继续）	请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101（切换协议）	请求者已要求服务器切换协议，服务器已确认并准备切换。

2xx （成功）

表示成功处理了请求的状态码。

200（成功）	服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。如果是对您的 robots.txt 文件显示此状态码，则表示 Googlebot 已成功检索到该文件。
201（已创建）	请求成功并且服务器创建了新的资源。
202（已接受）	服务器已接受请求，但尚未处理。
203（非授权信息）	服务器已成功处理了请求，但返回的信息可能来自另一来源。
204（无内容）	服务器成功处理了请求，但没有返回任何内容。
205（重置内容）	服务器成功处理了请求，但没有返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如，清除表单内容以输入新内容）。
206（部分内容）	服务器成功处理了部分 GET 请求。

3xx （重定向） 要完成请求，需要进一步操作。通常，这些状态码用来重定向。Google 建议您在每次请求中使用重定向不要超过 5 次。您可以使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。诊断下的网络抓取 (opens new window)页列出了由于重定向错误导致 Googlebot 无法抓取的网址。

300（多种选择）	针对请求，服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301（永久移动）	请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。
302（临时移动）	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动，因为 Googlebot 会继续抓取原有位置并编制索引。
303（查看其他位置）	请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。对于除 HEAD 之外的所有请求，服务器会自动转到其他位置。
304（未修改）	自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。如果网页自请求者上次请求后再也没有更改过，您应将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。服务器可以告诉 Googlebot 自从上次抓取后网页没有变更，进而节省带宽和开销。.
305（使用代理）	请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
307（临时重定向）	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 <a href=answer.py?answer=>301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个页面或网站已经移动，因为 Googlebot 会继续抓取原有位置并编制索引。

4xx（请求错误） 这些状态码表示请求可能出错，妨碍了服务器的处理。

400（错误请求）	服务器不理解请求的语法。
401（未授权）	请求要求身份验证。对于登录后请求的网页，服务器可能返回此响应。
403（禁止）	服务器拒绝请求。如果您在 Googlebot 尝试抓取您网站上的有效网页时看到此状态码（您可以在 Google 网站管理员工具诊断下的网络抓取页面上看到此信息），可能是您的服务器或主机拒绝了 Googlebot 访问。
404（未找到）	服务器找不到请求的网页。例如，对于服务器上不存在的网页经常会返回此代码。如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具“诊断”标签的 robots.txt 页 (opens new window)上看到此状态码，则这是正确的状态码。但是，如果您有 robots.txt 文件而又看到此状态码，则说明您的 robots.txt 文件可能命名错误或位于错误的位置（该文件应当位于顶级域，名为 robots.txt）。如果对于 Googlebot 抓取的网址看到此状态码（在”诊断”标签的 HTTP 错误页面 (opens new window)上），则表示 Googlebot 跟随的可能是另一个页面的无效链接（是旧链接或输入有误的链接）。
405（方法禁用）	禁用请求中指定的方法。
406（不接受）	无法使用请求的内容特性响应请求的网页。
407（需要代理授权）	此状态码与 <a href=answer.py?answer=35128>401（未授权）类似，但指定请求者应当授权使用代理。如果服务器返回此响应，还表示请求者应当使用代理。
408（请求超时）	服务器等候请求时发生超时。
409（冲突）	服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，以及两个请求的差异列表。
410（已删除）	如果请求的资源已永久删除，服务器就会返回此响应。该代码与 404（未找到）代码类似，但在资源以前存在而现在不存在的情况下，有时会用来替代 404 代码。如果资源已永久移动，您应使用 301 指定资源的新位置。
411（需要有效长度）	服务器不接受不含有效内容长度标头字段的请求。
412（未满足前提条件）	服务器未满足请求者在请求中设置的其中一个前提条件。
413（请求实体过大）	服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414（请求的 URI 过长）	请求的 URI（通常为网址）过长，服务器无法处理。
415（不支持的媒体类型）	请求的格式不受请求页面的支持。
416（请求范围不符合要求）	如果页面无法提供请求的范围，则服务器会返回此状态码。
417（未满足期望值）	服务器未满足”期望”请求标头字段的要求。

5xx（服务器错误） 这些状态码表示服务器在处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

500（服务器内部错误）	服务器遇到错误，无法完成请求。
501（尚未实施）	服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码。
502（错误网关）	服务器作为网关或代理，从上游服务器收到无效响应。
503（服务不可用）	服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。
504（网关超时）	服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505（HTTP 版本不受支持）	服务器不支持请求中所用的 HTTP 协议版本。

6. HTTP 缺点

• 明文传输，内容可能会被窃听

• 不验证通信方的身份，因此有可能遭遇伪装

• 无法证明报文的完整性，所以有可能已遭篡改

1. HTTP+加密+认证+完整性保护=HTTPS

   用SSL 将通信的报文主体内容进行加密，使用SSL 建立http 的安全通信线路，SSL 处于http与TCP 通信之间，这样的SSL 与HTTP 组合被称为HTTPS。HTTPS 采用对称加密和非对称加密两者并用的混合加密机制

2. Http和Https的区别

   Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

• 端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；

• 资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；

• 开销：Https通信需要证书，而证书一般需要向认证机构购买；

• Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

7. 其他常见协议

1. DHCP协议：一个局域网的网络协议，使用UDP协议工作，用途：给内部网络或网络服务供应商自动分配IP地址，给用户或者内部网络管理员作为对所有计算机作管理的手段。

2. 邮件传输用什么协议

   • SMTP：简单邮件传送协议：只能传送7位的ASCII码即只能传送ASCII码文件，不能传送其他二进制文件。

     • 连接建立：熟知端口号25

     • 邮件传送

     • 连接释放

   • MIME：通用互联网邮件扩充

   • POP3：邮局协议（邮件读取协议）：只要用户从POP3服务器读取了邮件，POP3服务器就将该邮件删除。POP3使用的是TCP连接，是有连接可靠的数据传输服务。

   • IMAP：网际报文存取协议：在用户未发出删除邮件的命令之前，IMAP服务器邮箱中的邮件一直保存着。

3. FTP和TFTP

   • FTP的工作模式和步骤

     • 一个FTP服务器进程由两大部分组成：一个主进程（负责接收新的请求），若干个从属进程（负责处理单个请求）

     • 主进程的工作步骤：

     • 打开熟知端口（21），使客户进程可以连接上

     • 等待客户进程发出连接请求。

     • 启动从属进程处理客户进程发来的请求。

   • 控制连接和数据连接（端口号分别是21和20）

   • TFTP（简单文件传送协议）

     • 使用UDP数据报

     • 熟知端口号：69

4. DHCP：动态主机配置协议

   • DHCP客户使用的UDP端口是68，而DHCP服务器使用的端口号是67

   • DHCP 工作过程如下：

     1. 客户端发送 Discover 报文，该报文的目的地址为 255.255.255.255:67，源地址为 0.0.0.0:68，被放入 UDP 中，该报文被广播到同一个子网的所有主机上。如果客户端和 DHCP 服务器不在同一个子网，就需要使用中继代理。
     2. DHCP 服务器收到 Discover 报文之后，发送 Offer 报文给客户端，该报文包含了客户端所需要的信息。因为客户端可能收到多个 DHCP 服务器提供的信息，因此客户端需要进行选择。
     3. 如果客户端选择了某个 DHCP 服务器提供的信息，那么就发送 Request 报文给该 DHCP 服务器。
     4. DHCP 服务器发送 Ack 报文，表示客户端此时可以使用提供给它的信息。

5. 常见协议及其端口号

应用	应用层协议	端口号	传输层协议	备注
域名解析	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
超文本传送协议	HTTPs	443	TCP/UDP
简单邮件传送协议	SMTP	25	TCP
邮件读取协议	POP3	110	TCP
网际报文存取协议	IMAP	143	TCP

8. 输入IP地址可以正常访问网页,输入域名不能访问？

答：因为DNS域名解析出了问题。

• 造成这一故障的原因，大都是因为ISP服务商的DNS服务器出了问题，或者是进行相关限制设置，当然有时也可能是因为本地DNS缓存发生故障引起的。

• 为了提高网站访问速度，系统会自动将已经访问过并获取了IP地址的网站存入本地的DNS缓存里，一旦再对这个网站进行访问，则不再通过DNS服务器而直接从缓存中取出该网站的IP地址进行访问。但有时就是因为本地DNS缓存出现了问题，而导致了网站无法访问的故障。

• 这时可以这样来排除故障，"运行"——cmd————ipconfig/flushdns，这样Windows系统就会重建本地DNS缓存，问题也就自然排除了。

9. Cookie的作用是什么?和Session有什么区别？

1. Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

2. Cookie 一般用来保存用户信息

①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；

②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；

③登录一次网站后访问网站其他页面不需要重新登录。

3. Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

4. Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

5. Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

10. URI和URL的区别是什么?

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。

• URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

• URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

  

http各版本的比较

http0.9

1. 最初的http版本，仅支持get方法，只能传输纯文本内容，所以请求结束服务段会给客户端返回一个HTML格式的字符串，然后由浏览器自己渲染。

2. http0.9是典型的无状态连接（无状态是指协议对于事务处理没有记忆功能，对同一个url请求没有上下文关系，每次的请求都是独立的，服务器中没有保存客户端的状态）

http1.0

1. 这个版本后任何文件形式都可以被传输，本质上支持长连接，但是默认还是短连接，增加了keep-alive关键字来由短链接变成长连接。

2. HTTP的请求和回应格式也发生了变化，除了要传输的数据之外，每次通信都包含头信息，用来描述一些信息。

3. 还增加了状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等

http1.1

1. HTTP1.1最大的变化就是引入了长链接，也就是TCP链接默认是不关闭的可以被多个请求复用。客户端或者服务器如果长时间发现对方没有活动就会关闭链接，但是规范的做法是客户端在最后一个请求的时候要求服务器关闭链接。对于同一个域名，目前浏览器支持建立6个长链接。

2. 节约带宽，HTTP1.1支持只发送header头信息不带任何body信息，如果服务器认为客户端有权限请求指定数据那就返回100，没有就返回401，当客户端收到100的时候可以才把要请求的信息发给服务器。并且1.1还支持了请求部分内容，如果当前客户端已经有一部分资源了，只需要向服务器请求另外的部分资源即可，这也是支持文件断点续传的基础。

3. 1.1版本中增加了host处理，在HTTP1.0中认为每台服务器都绑定一个唯一的ip地址，因此在URL中并没有传递主机名，但是随着虚拟机技术的发展，可能在一台物理机器上存在多个虚拟主机，并且他们共享了一个ip地址，http1.1中请求消息和响应消息都支持host头域，如果不存在还会报出错误

http2.0

1. 多路复用：在一个连接里面并发处理请求，不像http1.1在一个tcp连接中各个请求是串行的。花销很大

2. 在1.0版本后增加了header头信息，2.0版本通过算法把header进行了压缩这样数据体积就更小，在网络上传输就更快。

3. 服务端有了推送功能，将客户端感兴趣的东西推给客户端，当客户端请求这些时，直接去缓存中取就行。