计算机网络 - 面试篇

coderzpw

已于 2023-10-31 14:28:58 修改

阅读量4.4k

点赞数 19

分类专栏：面试 + 笔试操作系统（linux、windows）+网络文章标签：面试网络 http

于 2021-12-19 15:58:01 首次发布

本文链接：https://blog.csdn.net/qq_45464560/article/details/121736695

版权

面试 + 笔试同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

操作系统（linux、windows）+网络

5 篇文章 0 订阅

订阅专栏

计算机网络 - 面试篇

综合
物理层
数据链路层
- 谈谈你对 ARQ 协议的理解？
网络层
传输层
应用层
相关连接
- 推荐计网学习视频链接
- 借鉴优秀文章链接

综合

OSI七层模型

在这里插入图片描述

讲一下网络五层模型，每一层的职责？

物理层：
- 解决采用怎样的传播媒体（介质）问题
- 解决采用怎样的物理接口问题
- 解决使用怎样的信号表示比特0和1问题
数据链路层：
- 解决如何标识网络中的各主机（主机编码问题，例如MAC地址）问题
- 解决如何从信号表示的一连串比特流中区分出地址和数据问题
- 解决如何协调各主机争用总线问题
网络层：
- 解决如何标识各网络以及各网络中的各主机（网络和主机共同编制的问题，例如IP地址）问题
- 解决路由器如何转发分组，如何进行路由选择问题
运输层：
- 解决进程之间基于网络的通信问题
- 解决出现传输错误时，如何处理问题
应用层：
- 通过应用进程间的交互来完成特定的网络应用

在浏览器地址栏输入一个URL后回车，执行的全部过程

一共6个步骤：

DNS解析（这部分最好详细介绍）
TCP连接： 浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手
发送http请求： TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求
服务器处理请求：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器
浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面
连接结束

DNS解析

DNS，英文全称是Domain Name System，中文意思是域名系统。首先明确一点的是，DNS 是属于应用层的，并且它选择的运输层协议是 UDP
简单来说就是：浏览器查询DNS，根据域名获取对应的IP地址（一个域名可能对应多个IP地址）

根域名服务器(root Name server) 是互联网域名解析系统(DNS)中最高级别的域名服务器，负责返回顶级域的权威域名服务器地址。它们是互联网基础设施中的重要部分，因为所有域名解析操作均离不开它们。由于DNS和某些协议(未分片的用户数据协议(UDP)数据包在IPv4内的最大有效大小为512字节)的共同限制，根域名服务器地址的数量呗限制为13个。

顶级域名（TLD），就是最高层级的域名。简单说，就是网址的最后一个部分。比如，网址www.baidu.com的顶级域名就是.com。他们可以分成两类。一类是一般性顶级域名(gTLD)也可以叫通用顶级域名，比如.com、net、.edu、.org等等，共有700多个。另一类是国别顶级域名(ccTLD)，代表不同的国家和地区，比如.cn(中国)、.io(英属印度洋领地)等，共有300多个。

**名称服务器(Name Server)**在互联网中是指提供域名服务协议的程序或服务器。它可以将"人类可识别"的标识符，映射为系统内部通常为数字形式的标识码。域名系统(DNS)服务器是最著名的名称服务器:域名是互联网两大主要名字空间之一。

DNS解析过程（重点）

检查浏览器缓存中是否缓存过该域名对应的ip地址
如果在浏览器缓存中没有找到ip，那么将继续查找本机系统缓存是否缓存过ip
如果在本机系统缓存中没有找到ip，向本地域名服务器发起域名解析的请求
本地域名服务器向根域名解析服务器发起域名解析请求
根域名服务器返回顶级域服务器地址
本地域名服务器向顶级域名服务器发起解析请求
顶级域名服务器返回名称服务器（Name Server）地址
本地域名服务器向名称服务器发起解析请求
名称服务器返回ip地址给本地服务器
本地域名服务器缓存最终解析结果
最后返回解析结果给用户

DNS负载均衡: DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址，在应答NDS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。

tcp、udp、http、https等常用协议

1.HTTP(Hypertext Transfer Protocol) 超文本传输协议(80)
1).无状态(cookie/session keep-alive)
2).无连接
3).基于请求和响应
4).简单灵活
5).通信使用明文

2.HTTPS(Hypertext Transfer Protocol Secure)超文本传输安全协议(443)
1).HTTP+SSL(Netscape的安全套接层)
a).SSL((Secure Sockets Layer) 安全套接层(40-128)
b).TLS(Transport Layer Security) 传输层安全
2).数据加密(SSL);身份认证(CA证书[采用非对称加密])

3.TCP(Transmission Control Protocol)传输控制协议
1).面向连接
2).可靠传输的情况, 应用于文件传输, 重要状态更新等场景
3).传输大量数据
4).传输慢

4.UDP(User Data Protocol)用户数据协议
1).面向非连接
2).高速传输和实时性要求较高的通信领域(可靠性需要应用层控制)
3).传输少量数据
4).传输快

5.Socket(程序通过一个双向的通信连接实现数据的交换，连接的一端称为一个socket)(API)
1).socket本质是编程接口(API),对TCP/IP的封装,TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口
2).连接过程:服务器监听，客户端请求，连接确认
3).优势与劣势
A).优势:
a).传输数据为字节级，传输数据可自定义，数据量小
b).传输数据时间短，性能高
c).适合于客户端和服务器端之间信息实时交互
d).可以加密,数据安全性强
B).劣势:
a).需对传输的数据进行解析，转化成应用级的数据
b).相对于HTTP协议传输，增加了开发量
c).对开发人员的开发水平要求高
4).基于Socket传输的特点其适用于对传输速度，安全性，实时交互，费用等要求高的应用中，如网络游戏，手机应用，银行内部交互等

6.TCP/IP(TCP/IP Protocol Suite)TCP/IP协议族
1).四层模型
a).应用层有FTP、HTTP、TELNET、SMTP、DNS等协议
b).传输层有TCP协议与UDP协议
c).网络层有IP协议、ICMP协议、ARP(地址解析)协议、RARP(反向地址解析)协议和BOOTP协议
d).网络接口层有FDDI、Ethernet、Arpanet、PDN、SLIP、PPP、IEEE802.1A、IEEE802.2-IEEE802.11
2).五层模型
a).应用层有FTP、HTTP、TELNET、SMTP、DNS等协议
b).传输层有TCP协议与UDP协议
c).网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议
d).数据链路层有FDDI、Ethernet、Arpanet、PDN、SLIP、PPP
e).物理层有IEEE802.1A、IEEE802.2- IEEE802.11等协议

Cookie 和 Session 有什么区别？

Session

由于HTTP协议是无状态的协议，所以服务端为了记录用户的状态时，就需要用某种机制来识具体的用户，这个机制就是Session。典型的场景比如购物车。

当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，并且跟踪用户，这样才知道购物车里面有几本书。

这个Session是保存在服务端的，有一个唯一标识。在服务端保存Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存服务比如Memcached之类的来放 Session。

Cookie

而服务端为了识别特定的客户，Cookie就登场了。
每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。

如果客户端的浏览器禁用了 Cookie 怎么办？
一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。

Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。

总结：

Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中
Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

请说一下同步，异步；阻塞，非阻塞

同步与异步

同步和异步关注的是消息通信机制

所谓同步，就是由调用者主动等待这个调用的结果
而异步则是相反，当一个异步过程调用发出后，调用者不会立刻得到结果，而是在调用发出后，被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用。

举个通俗的例子：
你打电话问书店老板有没有《计算机网络》这本书，如果是同步通信机制，书店老板会说，你稍等，”我查一下"，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结果）。
而异步通信机制，书店老板直接告诉你我查一下啊，查好了打电话给你，然后直接挂电话了（不返回结果）。然后查好了，他会主动打电话给你。在这里老板通过“回电”这种方式来回调。

阻塞与非阻塞

阻塞和非阻塞关注的是程序（线程）在等待调用结果（消息，返回值）时的状态

阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回
非阻塞调用是指在不能立刻得到结果之前，该调用不会阻塞当前线程。

还是上面的例子，你打电话问书店老板有没有《分布式系统》这本书，你如果是阻塞式调用，你会一直把自己“挂起”，直到得到这本书有没有的结果，如果是非阻塞式调用，你不管老板有没有告诉你，你自己先一边去玩了，当然你也要偶尔过几分钟check一下老板有没有返回结果。在这里阻塞与非阻塞与是否同步异步无关。跟老板通过什么方式回答你结果无关。

什么是SQL 注入？举个例子？如何防止SQL注入?

什么是SQL 注入？

SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

举个例子？

变量ShipCity的值由用户提交，在正常情况下，加入用户输入的是"Beijing" 那么SQL 语句会执行:

SELECT * FROM OrdersTable WHERE ShipCity = 'Beijing';

但假如用户输入一段有语义的SQL语句，比如:

beijing’;drop table OrdersTable–

他的请求为

http://localhost:8080/ExcelUsingXSLT/Default.aspx?shipcity=beijing’;drop table OrdersTable–
那么， SQL 语句在实际执行时就会如下:

SELECT * FROM OrdersTable WHERE ShipCity='Beijing'; drop table OrdersTable--'

结果直接删表的，这种就是恶意攻击

如何防止SQL注入?

采用预编译技术。使用预编译的SQL语句，SQL语句的语义是不会发生改变的。预编译语句在创建的时候就已经将指定的SQL语句发送给了DBMS，完成了解析，检查，编译等工作。
对特殊的字符进行转义。比如在MySQL中我们可以对" ’ "进行转义，这样就防止了一些恶意攻击者来闭合语句。
就知道这俩。。。。

谈一谈 XSS 攻击，举个例子？

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。

XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

（就知道这些了，(#^.^#)！！！）

物理层

数据链路层

谈谈你对 ARQ 协议的理解？

自动重传请求（Automatic Repeat-ReQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。
ARQ协议主要包含：停止-等待ARQ协议、连续ARQ协议。其中连续ARQ协议是为了解决停等ARQ协议信道利用率低的问题，目前传统的连续ARQ协议有回退N帧ARQ协议、选择性重传ARQ协议。
注意： AQR协议的一个特点是：发送窗口的大小 <= 窗口总数

停等ARQ协议（stop-and-wait）：

停等ARQ协议相当于发送窗口和接收窗口大小均为1的滑动窗口协议。即发送方发送一个帧后，必须接收到一个确认帧（ACK）才能发送下一个。
在这里插入图片描述
原理：

点对点发送数据报，等待接收端回复并开始计时
等待开始时，发送端停止发送新数据包
当数据包没有成功被接收端接收时，接收端不发送ACK包，发送端将继续等待一段时间并重新发送数据包
重复以上步骤，直到接收到接收端发来的ACK

优点：
原理简单，广泛运用于分组交换网络。
缺点：
较长的等待时间，使得数据传输速度低。低速传输时频道利用率较高，高速传输时频道利用率较低。

连续ARQ协议（Continuous ARQ）

为了克服停等ARQ协议长时间等待ACK的缺点，这个协议会连续发送一组数据包，然后再等待这些数据包的ACK。
在这里插入图片描述
回退N帧ARQ协议（Go-Back-N）:
原理：

接收端丢弃从第一个没有收到的数据包开始的所有数据包
发送端收到NACK后，从NACK中指明的数据包开始重新发送

选择性重传ARQ协议（Selective Repeat）:
原理：

发送端连续发送数据包但对每个数据包都设有个一个计时器
当在一定时间内没有收到某个数据包的ACK时，发送端只重新发送那个没有ACK的数据包

网络层

说一下IP地址的作用，以及MAC地址的作用。

简单着说，IP 地址主要用来网络寻址用的，就是大致定位你在哪里，而 MAC 地址，则是身份的唯一象征，具体定位你在哪里，通过 MAC 来唯一确认这人是不是就是你。

主要区别：

地址性质不同：MAC地址是物理地址，每个硬件出厂时的MAC地址是固定的，且MAC地址具有唯一性；IP地址是逻辑地址，IP地址是可以更改的，IP地址不具备唯一性。
所在寻址协议层上的区别：MAC地址应用在数据链路层，通过MAC地址，数据链路层协议可以使数据从一个节点传递到相同链路的另一个节点上；IP地址应用于网络层，通过IP地址，网络层协议使数据可以从一个网络传递到另一个网络上。
长度定义不同：MAC地址是Ethernet网卡上带的地址，长度为48位，IP地址目前主流是32位长。
分配依据不同：MAC地址的分配是基于制造商；IP地址的分配是基于网络拓扑。

ARP协议的工作过程

ARP（Address Resolution Protocol）地址解析协议（在TCP/IP模型中ARP协议属于网络层）
该协议的作用：根据IP地址找到对应的MAC地址
ARP协议的工作过程：
- 一、首先每个主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址与MAC地址的映射关系
- 二、当源主机要发送数据时，首先检查ARP列表中是否有对应的目标IP地址映射MAC地址的信息。如果有，则直接发送数据；如果没有，就向本网段的所有主机发送ARP数据包，该数据包包括的内容有：源主机IP地址，源主机MAC地址，目的主机的IP地址
- 三、当本网络中的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包；如果是，则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中，如果已经存在，则覆盖，然后将自己的MAC地址写入ARP响应包中，告诉源主机自己是它想找的MAC地址
- 四、源主机收到ARP响应包后。将目标主机的IP和MAC地址写入到ARP列表中，并利用此信息发送数据。如果源数据一直没有收到ARP响应数据包，表示ARP查询失败。
ARP协议只能在一段链路或者一个网络上使用，而不能跨网络使用（一般情况下，ARP协议的使用是逐段链路进行的）

IP地址有哪些分类？

在这里插入图片描述

A类地址(1~126)：网络号占前8位，以二进制0开头，主机号占后24位。（网络号为127，作为本地回测地址，不指派）
B类地址(128~191)：网络号占前16位，以二进制10开头，主机号占后16位。
C类地址(192~223)：网络号占前24位，以二进制110开头，主机号占后8位。
D类地址(224~239)：以二进制1110开头，保留位多播地址。
E类地址(240~255)：以二进制1111开头，保留位今后使用。

注意：
只有A类、B类和C类地址可分配给网络中的主机和路由器的各接口
主机号为“全0”的地址是网络地址，不能分配给主机或者路由器中的各接口
主机号为“全1”的地址是广播地址，不能分配给主机或者路由器中的各接口

IPV4 地址不够如何解决

目前主要有以下两种方式：

其实我们平时上网，电脑的 IP 地址都是属于私有地址，我无法出网关，我们的数据都是通过网关来中转的，这个其实 NAT 协议。
NAT（Network Address Translation）是地址转换协议，将内网地址转换为公网地址。
简单的说，NAT就是在局域网内部网络中使用内部地址，而当内部节点要与外部网络进行通讯时，就在网关处，将内部地址替换成公用地址，从而在外部公网（internet）上正常使用，NAT可以使多台计算机共享Internet连接，这一功能很好地解决了公共IP地址紧缺的问题。
IPv6 ：作为接替 IPv4 的下一代互联网协议，其可以实现 2 的 128 次方个地址，而这个数量级，即使是给地球上每一颗沙子都分配一个IP地址，该协议能够从根本上解决 IPv4 地址不够用的问题。

ICMP 有哪些应用？

ICMP介绍：
ICMP全称 Internet Control Message Protocol 网际控制报文协议；
为了有效的转发IP数据报和提高交付成功的机会，在网际层使用了网际控制报文协议；
主机或路由器使用ICMP来发送差错报告报文和询问报文
ICMP报文被封装在IP数据报中发送

ICMP 主要有两个应用，一个是 Ping，一个是 Traceroute。
1. Ping
Ping（Packet InterNet Grouper，分组网间探测）是 ICMP 的一个重要应用，主要用来测试主机或路由器之间的连通性。
Ping 的原理是通过向目的主机发送 ICMP 请求报文，目的主机收到之后会发送 回答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

测试如下图：
在这里插入图片描述
2. Traceroute

Traceroute 是 ICMP 的另一个应用，用来跟踪IP数据报从源主机到达目的主机要经过哪些路由。

原理：

源主机向目的主机发送一连串的 IP 数据报。第一个数据报 P1 的生存时间 TTL 设置为 1，当 P1 到达路径上的第一个路由器 R1时，R1 收下它并把 TTL 减 1，此时 TTL 等于 0，R1 就把 P1 丢弃，并向源主机发送一个 ICMP 时间超过差错报告报文；
源主机接着发送第二个数据报 P2，并把 TTL 设置为 2。P2 先到达 R1，R1 收下后把 TTL 减 1 再转发给 R2，R2 收下后也把 TTL 减 1，由于此时 TTL 等于 0，R2 就丢弃 P2，并向源主机发送一个 ICMP 时间超过差错报文。
不断执行这样的步骤，直至目标地址收到探测数据包，并返回ICMP回应答复
之后源主机知道了到达目的主机所经过的路由器 IP 地址以及到达每个路由器的往返时间。

在这里插入图片描述
测试如下图：

在这里插入图片描述

传输层

TCP 特点

TCP协议的主要特点：

TCP是面向连接的运输层协议；所谓面向连接就是双方传输数据之前，必须先建立一条通道，例如三次握手就是建议通道的一个过程，而四次挥手则是结束销毁通道的一个其中过程。
每一条TCP连接只能有两个端点（即两个套接字），只能是点对点的。
TCP提供可靠的传输服务。传送的数据无差错、不丢失、不重复、按序到达。
TCP提供全双工通信。允许通信双方的应用进程在任何时候都可以发送数据，因为两端都设有发送缓存和接受缓存。

TCP的可靠性原理：
那么TCP是怎样保证可靠性的呢？

首先，采用三次握手来建立TCP连接，四次挥手来释放TCP连接，从而保证建立的传输信道是可靠的。
其次，TCP采用了连续ARQ协议（回退N，Go-back-N；超时自动重传）来保证数据传输的正确性，使用滑动窗口协议来保证接方能够及时处理所接收到的数据，进行流量控制。
最后，TCP使用慢开始、拥塞避免、快重传和快恢复来进行拥塞控制，避免网络拥塞。

TCP报文段

TCP报文段首部最小20字节，最大60字节
在这里插入图片描述

谈下你对 TCP 流量控制的理解？

TCP利用滑动窗口来实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口的大小，从而影响发送方的发送速率。当窗口字段设置为0，则发送方不能发送数据。

谈谈你对 TCP 滑动窗口的了解？

TCP 利用滑动窗口实现流量控制的机制。滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。

TCP采用滑动窗口来进行流量传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应发送多少字节的数据。当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程；另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。
在这里插入图片描述

谈下你对 TCP 拥塞控制的理解？使用了哪些算法？

拥塞控制和流量控制不同，流量控制针对的是点对点通信量的控制，而拥塞控制则是一个全局性的过程。

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫做阻塞。（在计算机网络中的宽带、交换节点中的缓存和处理机等，都是网络的资源）
若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大儿下降。
在这里插入图片描述

为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。
在这里插入图片描述

慢开始：
慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
拥塞避免：
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间就把发送方的 cwnd 加 1。
快重传与快恢复：
在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。
没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停，等超时重传计时器超时再重传，在等待的这段时间内，没有新的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。
有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和快恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

TCP 协议是如何保证可靠传输的？

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据
对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据
应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒
超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段
流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议

TCP 最大连接数限制

如何标识一个TCP连接：
在确定最大连接数之前，先来看看系统如何标识一个tcp连接。系统用一个4四元组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。

client最大tcp连接数：
client每次发起tcp连接请求时，除非绑定端口，通常会让系统选取一个空闲的本地端口（local port）,该端口是独占的，不能和其他tcp连接共享。本地端口个数最大只有65536（2^16），端口0有特殊含义，不能使用，这样可用端口最多只有65535，所以在全部作为client端的情况下，最大tcp连接数为65535，这些连接可以连到不同的服务端。

server最大tcp连接数：（理论上）
server通常固定在某个本地端口上监听，等待client的连接请求。不考虑地址重用（unix的SO_REUSEADDR选项）的情况下，即使server端有多个ip，本地监听端口也是独占的，因此server端tcp连接4元组中只有remote ip（也就是client ip）和remote port（客户端port）是可变的，因此最大tcp连接为客户端ip数×客户端port数，对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。

实际server的tcp连接数：
面给出的是理论上的单机最大连接数，在实际环境中，受到机器资源、操作系统等的限制，特别是sever端，其最大并发tcp连接数远不能达到理论上限。在unix/linux下限制连接数的主要因素是内存和允许的文件描述符个数（每个tcp连接都要占用一定内存，每个socket就是一个文件描述符），另外1024以下的端口通常为保留端口。在默认2.6内核配置下，经过试验，每个socket占用内存在15~20k之间。
对server端，通过增加内存、修改最大文件描述符个数等参数，单机最大并发TCP连接数超过10万是没问题的

描述一下三次握手。两次握手可不可以？

三次握手过程

第一次握手： TCP客户端进程向TCP服务端进程发出连接请求报文段，首部的同部位SYN=1、初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序列号。此时TCP客户端进程进入SYN-SENT（同步-发送）状态。

第二次握手： TCP服务端进程收到连接请求报文段后，如果同意连接，则向TCP客户端进程发送确认-连接请求报文，报文首部的同步位SYN=1、确认位ACK=1、确认号ack=x+1、初始序号seq=y。此时TCP服务端进程进入SYN-RCVD（同步-收到）状态。

第三次握手： TCP客户进程收到TCP服务端进程的确认后，要向TCP服务端进程给出确认报文段，首部确认位ACK=1、确认号ack=y+1、序号seq=x+1，该报文段是可以携带数据的。TCP连接已经建立，TCP客户端进程进入ESTABLISHED状态（established:已建立连接）。当TCP服务端进程收到TCP客户端进程的确认后，也进入ESTABLISHED状态。
在这里插入图片描述

不可以两次握手！

主要是为了防止已失效的连接请求报文突然又传到TCP服务器进程，从而导致错误。
如果使用的是两次握手建立连接，假设有这样一种场景。

客户端发送的第一个连接请求没有丢失，但是在网络中滞留的时间太长了。
由于客户端迟迟没有收到服务端的确认报文，以为第一个连接请求报文已经丢失，此时重新向服务端发送这条连接请求报文。
此后客户端和服务器经过两次握手完成连接，传输数据，最后关闭连接。
此时之前滞留的那一次请求连接报文，因为网络通畅了, 到达了服务端。服务端会误认为这是客户端发起的一个新的连接请求，于是给客户端发送连接请求确认报文并进入连接已建立状态，它认为新的连接已建立好了，并一直等待客户端发来数据，这将白白浪费服务端所在主机的很多资源。

在这里插入图片描述

什么是半连接队列？

Linux内核协议栈为一个tcp连接管理使用两个队列。
一个是半连接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求）。
一个是全连接队列（用来保存处于established状态的请求），如果队列满了就会出现丢包现象。

这里在补充一点关于SYN-ACK 重传次数的问题：
服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

ISN(Initial Sequence Number)是固定的吗？

ISN即初始序列号。
当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据
为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。
常见的防御 SYN 攻击的方法有如下几种：

缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护

TCP建立连接过程中，第三次握手seq=1000,ack=2000.问第二次握手seq和ack分别为多少？

首先我们需要知道几个概念:

序列号seq: 占4个字节，用来标记数据段的顺序,就是这个报文段中的第一个字节的数据编号
确认号ack: 占4个字节，期待收到对方下一个报文段的第一个数据字节的序号
同步SYN: 连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。
确认ACK: 占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

第一次握手：建立连接时，客户端发送SYN包（seq=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到SYN包，将SYN和ACK标识都置为1,然后设置（seq=y,ack=x+1），向客户端发送一个SYN+ACK包，此时服务器进入SYN_RECV状态.
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包,将ACK置为1,S此时无需SYN,(seq=x+1,ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

所以 :
这题中,第三次的seq = x + 1 = 2000,ack = y + 1 = 1000,说明第二次的seq = y = 1999,ack = x + 1 = 1000

描述一下四次挥手。为什么客户端在TIME-WAIT状态必须等待2MSL的时间？挥手为什么需要四次？

四次挥手过程

第一次挥手： 客户端向服务端发送连接释放报文（FIN=1，序号seq=u），并停止再发送数据，进入FIN-WAIT-1（终止等待1）状态，等待服务端的确认。
第二次挥手： 服务端收到连接释放报文后即发送确认报文（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE-WAIT（关闭等待状态）。客户端收到服务端的确认后，进入FIN-WAIT-2（终止等待2）状态，等待服务端向自己发送连接释放报文。此时客户端到服务端这个方向的连接就释放了，TCP处于半关闭状态。
第三次挥手： 服务端向客户端发送连接释放报文（FIN=1，ACK=1，确认号ack=u+1，序号seq=w），服务端进入LAST-ACK（最后确认）状态，等待客户端的确认。
第四次挥手： 客户端收到连接释放报文后即发送 确认报文（ACK=1，确认号ack=w+1，序号seq=u+1），客户端进入TIME-WAIT（时间等待）状态，此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

MSL（Maximun Segment Lifetime）意思是最长报文段寿命，一个MSL建议是2分钟。
在这里插入图片描述

为什么客户端在TIME-WAIT状态必须等待2MSL的时间？

为了确保客户端发送的最后一个ACK报文段能够到达服务端
并保证本次连接持续时间内所产生的所有报文段都从网络中消失

假如客户端收到服务端发送的连接释放报文后，并向服务端发送普通的TCP确认报文后，不再等待2MSL的时间，直接进入CLOSED（关闭）状态。然后该TCP确认报文在网络组丢失了，这必然会造成服务端进程对之前发送的TCP连接释放报文的超时重发，但由于客户端处于关闭状态，因此不会理睬该报文段，这必然会造成服务端进程反复重传TCP连接释放报文，而无法进入关闭状态。

挥手为什么需要四次？三次可不可以？

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。

但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET（因为服务端可能还有些数据没有发送完），所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

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

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。

TCP保活计时器的作用？

TCP保活计时器，tcp keepaliveTCP。
双方（客户端和服务端）已建立了连接，但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。

服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10个 探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。

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

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

UDP 特点

UDP是无连接的传输层协议
UDP使用尽最大努力交付，不保证可靠交付
UDP是面向报文的，对应用层交下来的报文，不合并，不拆分，保留原报文的边界
UDP没有拥塞控制，因此即使网络出现拥塞也不会降低发送速率
UDP支持一对一　一对多　多对多的交互通信
UDP的首部开销小，只有８字节

UDP用户数据报

UDP用户数据报首部仅有8字节
在这里插入图片描述

UDP 如何实现可靠传输？

UDP不属于连接协议，具有资源消耗少，处理速度快的优点，所以通常音频，视频和普通数据在传送时，使用UDP较多，因为即使丢失少量的包，也不会对接受结果产生较大的影响。
传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。

添加seq/ack机制，确保数据发送到对端
添加发送和接收缓冲区，主要是用户超时重传
添加超时重传机制

详细说明：发送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。

目前利用udp实现了可靠的数据传输的开源程序有RUDP、RTP、UDT。

1、RUDP（Reliable User Datagram Protocol）
RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等，从而在包丢失和网络拥塞的情况下， RTP 客户机（实时位置）面前呈现的就是一个高质量的 RTP 流。在不干扰协议的实时特性的同时，可靠 UDP 的拥塞控制机制允许 TCP 方式下的流控制行为。
2、RTP（Real Time Protocol）
RTP为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么 RTP 可以使用该组播表传输数据到多个目的地。
3、UDT（UDP-based Data Transfer Protocol）
基于UDP的数据传输协议（UDP-basedData Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。

DNS 为什么用 UDP？

其实 DNS 的整个过程是既使用 TCP 又使用 UDP。

当进行区域传送（主域名服务器向辅助域名服务器传送变化的那部分数据）时会使用 TCP，因为数据同步传送的数据量比一个请求和应答的数据量要多，而 TCP 允许的报文长度更长，因此为了保证数据的正确性，会使用基于可靠连接的 TCP。

当客户端向 DNS 服务器查询域名 ( 域名解析) 的时候，一般返回的内容不会超过 UDP 报文的最大长度，即 512 字节。用 UDP 传输时，不需要经过 TCP 三次握手的过程，从而大大提高了响应速度，但这要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。

TCP 和 UDP的区别

TCP是可靠传输,UDP是不可靠传输
TCP面向连接,UDP无连接
TCP传输数据有序,UDP不保证数据的有序性
TCP不保存数据边界,UDP保留数据边界
TCP传输速度相对UDP较慢
TCP有流量控制和拥塞控制,UDP没有
TCP是重量级协议,UDP是轻量级协议
TCP首部较长２０字节,UDP首部较短８字节

基于 TCP 和 UDP 的常用协议

基于可靠的TCP协议：
HTTP、HTTPS、FTP、TELNET、SMTP
基于不可靠的UDP协议：
TFTP、DNS、DHCP、TFTP、SNMP(简单网络管理协议)、RIP

TCP 和 UDP 应用场景

TCP应用场景：
效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
UDP应用场景：
效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）

请你说说传递到IP层怎么知道报文该给哪个应用程序？它怎么区分UDP报文还是TCP报文？

使用端口号来区分不同的应用进程（应用进程）
IP数据报首部中协议字段的值，如果是17表示UDP报文，如果是6表示TCP报文。

在这里插入图片描述

介绍一下tcp粘包与拆包

假设客户端分别发送了两个数据包D1和D2给服务器，由于服务器一次读取的字节数是不确定的，故可能存在以下4中情况：

服务端分两次读到了两个独立的数据包D1和D2，没有粘包和拆包
服务端分一次收到两个数据包，D1和D2粘合一起，被称为TCP粘包
服务端分两次读取到了两个数据包，第一次完成的D1和D2部分，第二次是D2剩余部分，被称为TCP拆包
服务端分两次读到了两个数据包，第一次读到D1的部分内容，第二次是D1剩下的内容和D2全部包，拆包
也有可能，D1和D2过大，服务器需要多次接收，多次拆包

什么是粘包？

如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；
从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。

基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。

接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难，因为无法区分一个完整的数据包。

TCP 粘包是怎么产生的？

发送方产生粘包：
采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过小时，那么 TCP会将这些较小的数据包进行合并发送，这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。
接收方产生粘包
接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（C 语言用 recv、read 等函数）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）

怎么解决拆包和粘包？

分包机制一般有两个通用的解决方法：

特殊字符控制；
在包头首都添加数据包的长度。

UDP 没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报，发送的时候既不合并，也不拆分。

应用层

常见的web请求返回的状态码

2xx - 客户端请求已成功。
200 - 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页
201 - 已创建，请求成功并且服务器创建了新的资源
202 - 已接受，但尚未处理
203 - 非权威性信息，服务器已成功处理了请求，但返回的信息可能来自另一来源
204 - 无内容，服务器成功处理了请求，但没有返回任何内容
205 - 重置内容，服务器成功处理了请求，但没有返回任何内容
206 - 部分内容，服务器成功处理了部分 GET 请求
3xx - 重定向
302 - 对象已移动
304 - 未修改
307 - 临时重定向
404 -Not Found 代表客户端错误，指的是服务器端无法找到所请求的资源
400 -请求无效，服务器不理解请求的语法
403 - 禁止访问，服务器拒绝请求
405 - 资源被禁止，禁用请求中指定的方法
406 - 无法接受，无法使用请求的内容特性响应请求的网页
407 - 要求代理身份验证，此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理
408 - 请求超时，服务器等候请求时发生超时
409 - 冲突，服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息
410 - 已删除，如果请求的资源已永久删除，服务器就会返回此响应。
411 - 需要有效长度，服务器不接受不含有效内容长度标头字段的请求。
412 - 未满足前提条件，服务器未满足请求者在请求中设置的其中一个前提条件。
413 - 请求实体过大，服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 - 请求的 URI 过长，请求的 URI（通常为网址）过长，服务器无法处理。
415 - 不支持的媒体类型，请求的格式不受请求页面的支持。
416 - 请求范围不符合要求，如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 - 未满足期望值，服务器未满足”期望”请求标头字段的要求
500 - 内部服务器错误，无法完成请求
501 - 未实现，服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码
502 - 网关错误，服务器作为网关或代理，从上游服务器收到无效响应
503 - 服务不可用，服务器目前无法使用，通常，这只是暂时状态
504 - 网关超时，服务器作为网关或代理，但是没有及时从上游服务器收到请求
505 - HTTP 版本不受支持，服务器不支持请求中所用的 HTTP 协议版本

HTTP1.0，1.1，2.0 的版本区别？

HTTP/1.0

HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。
这种方式就好像我们打电话的时候，只能说一件事儿一样，说完之后就要挂断，想要说另外一件事儿的时候就要重新拨打电话。

HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用。也就是说每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

我们知道TCP连接的建立需要三次握手，是很耗费时间的一个过程。所以，HTTP/1.0版本的性能比较差。

HTTP1.0 其实也可以强制开启长链接，例如接受Connection: keep-alive 这个字段，但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

HTTP/1.1

相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接。所谓的持久连接即TCP连接默认不关闭，可以被多个请求复用。
HTTP/1.1版还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。有了持久连接和管道，大大的提升了HTTP的效率。但是服务端还是顺序执行的，效率还有提升的空间。
HTTP/1.0定义了三种请求方法：GET、POST、和HEAD方法
HTTP/1.1新增了五种方法：OPTIONS，PUT，CONNECT，DELETE和TRACE方法。

HTTP/2

HTTP/2 为了解决HTTP/1.1中仍然存在的效率问题，HTTP/2 采用了多路复用。即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。能这样做有一个前提，就是HTTP/2进行了二进制分帧，即 HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。

HTTP/2采用二进制格式而非文本格式
HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
Header压缩: 使用报头压缩，HTTP/2降低了开销
服务端推送: HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

Http2中的多路复用

多路复用代替原来的序列和阻塞机制。所有就是请求的都是通过一个 TCP 连接并发完成。因为在多路复用之前所有的传输是基于基础文本的，在多路复用中是基于二进制数据帧的传输、消息、流，所以可以做到乱序的传输。多路复用对同一域名下所有请求都是基于流，所以不存在同域并行的阻塞。多次请求如下图：
在这里插入图片描述
总结
在 HTTP/2 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。
帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。

HTTP2 采用二进制数据帧传输，取代了 HTTP1.x 的文本格式，二进制格式解析更高效

多路复用代替了 HTTP1.x 的序列和阻塞机制，所有的相同域名请求都通过同一个 TCP 连接并发完成。同一 Tcp 中可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

connetion:keep-alive;

HTTP 如何实现长连接？在什么时候会超时？

HTTP 如何实现长连接？

通过在头部（请求和响应头）设置 Connection: keep-alive，HTTP1.0协议支持，但是默认关闭，从HTTP1.1协议以后，连接默认都是长连接

在什么时候会超时？

HTTP 一般会有 httpd 守护进程，里面可以设置 keep-alive timeout，当 tcp链接闲置超过这个时间就会关闭，也可以在 HTTP 的 header 里面设置超时时间
TCP 的 keep-alive 包含三个参数，支持在系统内核的 net.ipv4 里面设置：当 TCP 链接之后，闲置了 tcp_keepalive_time，则会发生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了 tcp_keepalive_probes，就会丢弃该链接。
- （1）tcp_keepalive_intvl = 15
  （2）tcp_keepalive_probes = 5
  （3）tcp_keepalive_time = 1800

谈下你对 HTTP 长连接和短连接的理解？分别应用于哪些场景？

谈下你对 HTTP 长连接和短连接的理解？

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如：JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。

而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
Keep-Alive 不会永久保持连接，它有一个保持时间。

HTTP 长连接、短连接使用场景是什么?

长连接：
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。例如： 数据库的连接用长连接

短连接：
而像 WEB 网站的 http 服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接。

HTTP发送请求和接收响应的整个流程

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

1. 建立TCP连接
在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能进行更高层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。

2. Web浏览器向Web服务器发送请求命令
一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET/sample/hello.jsp HTTP/1.1。

3. Web浏览器发送请求头信息
浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

4. Web服务器应答
客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。

5. Web服务器发送应答头信息
正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

6. Web服务器向浏览器发送数据
Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。

7. Web服务器关闭TCP连接
一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码：Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

HTTP请求信息由3部分组成：
在这里插入图片描述

请求行：请求方法（GET/POST）、URI、协议/版本
请求头(Request Header)
请求正文（请求体）

长连接问题，连接过程网络断开怎么办，在客户端和服务端分别需要做什么处理？

如果连接建立后，不通信是不知道网络已经断开的（在未设置Keep-Alive的情况下），除非你用send发了一个包出去，这时候一般会超时，如果中间路由器能够检测到网络出现故障的话，也会返回给你一个“网络不可达”或“主机不可达”的错误。

所以，要检测网络连接状况，必须发包才能知道，每隔一段时间发一个包以检测网络情况，即所谓“心跳”。

POST和GET有哪些区别？各自应用场景？

区别:

参数位置：

GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。

因为 URL 只支持 ASCII 码，因此 GET 的参数中如果存在中文等字符就需要先进行编码。例如中文会转换为 %E4%B8%AD%E6%96%87，而空格会转换为 %20。POST 参数支持标准字符集。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1Copy to clipboardErrorCopied
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2Copy to clipboardErrorCopied

参数类型：
GET只允许ASCII字符，POST没有限制

传输的数据大小：

GET提交的数据比较少，最多1024B
而POST可以传送更多的数据

安全性（对于传输的数据来说）：
POST的安全性与GET相比相对较高，GET的参数会暴露在URL上，而POST的参数则是在请求体中保存。
然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文，要想安全传输，就只有加密

幂等性区别：
幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

在正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。

是否可缓存：
如果要对响应进行缓存，需要满足以下条件：

请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST在多数情况下不可缓存的。
响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
响应报文的 Cache-Control 首部字段没有指定不进行缓存。

各自应用场景？

GET 用于获取资源，查询数据
POST 用于传输实体主体，修改数据

GET请求中URL编码的意义

在GET请求中浏览器会对URL中非西文字符进行编码，这样做的目的就是为了 避免歧义。

现在考虑这样一个问题，如果我们的参数值中就包含 = 或 & 这种特殊字符的时候该怎么办？例如：
“name1=value1”，其中value1的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。这样，我们的本意是只有一个键值对，但是服务端却会解析成两个键值对，这样就产生了歧义。

那么，如何解决上述问题带来的歧义呢？解决的办法就是对参数进行URL编码：例如，我们对上述会产生歧义的字符进行URL编码后结果：“name1=va%26lu%3De1”，这样服务端会把紧跟在“%”后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符

既然post有这么多优点，那我们为什么要使用get？

幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

get表达的是一种幂等的，只读的，纯粹的操作，不会因为多次点击而产生了副作用，因此绝大部分get请求（通常超过90%）都可以直接被缓存，这能大大减少web服务器负担。

而post所表达的语义是非幂等的，有副作用的操作，所以必须交由web服务器处理，不能缓存。

URI和 URL之间的区别

URL，即统一资源定位符 (Uniform Resource Locator )，URL 其实就是我们平时上网时输入的网址，它标识一个互联网资源，并指定对其进行操作或获取该资源的方法。例如 https://leetcode-cn.com/problemset/all/ 这个 URL，标识一个特定资源并表示该资源的某种形式是可以通过 HTTP 协议从相应位置获得。

而 URI 则是统一资源标识符，URL 是 URI 的一个子集，两者都定义了资源是什么，而 URL 还定义了如何能访问到该资源。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。简单地说，只要能唯一标识资源的就是 URI，在 URI 的基础上给出其资源的访问方式的就是 URL。

403和500状态分别讲解一下，他们之间有什么区别？

403：服务器拒绝请求
导致403状态码的常见原因有：

你的IP被列入黑名单
在当前目录下你没有执行权限
你在一定时间内过多的访问此网站，没防火墙拒绝访问了
DNS解析错误
连接的用户过多，可以过后再试

500：服务器遇到错误，无法完成请求（一般是服务端代码错误）

forward 和 redirect 的区别？

Forward 和 Redirect 代表了两种请求转发方式：直接转发和间接转发。

在学习Servlet和JSP时，经常会使用到forward和redirect，我们先来看这两者在Servlet中的调用方式：
1.forward

request.getRequestDispatcher("new.jsp").forward(request, response);   //转发到new.jsp

2.redirect

response.sendRedirect("new.jsp");   //重定向到new.jsp

很明显一个是用request对象调用，一个是用response对象调用，那么，这两者有什么区别呢？

一、数据共享方面

forward:转发页面和转发到的页面可以共享request里面的数据
redirect:不能共享数据

二、地址栏显示方面

forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址.
redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL.

三、本质区别
转发是服务器行为，重定向是客户端行为。

转发过程： 客户浏览器发送http请求—>web服务器接受此请求—>调用内部的一个方法在容器内部完成请求处理和转发动作—>将目标资源发送给客户；在这里，转发的路径必须是同一个web容器下的url，其不能转向到其他的web路径上去，中间传递的是自己的容器内的request。在客户浏览器路径栏显示的仍然是其第一次访问的路径，也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。

重定向过程： 客户浏览器发送http请求—>web服务器接受后发送302状态码响应及对应新的location给客户浏览器—>客户浏览器发现是302响应，则自动再发送一个新的http请求，请求url是新的location地址—>服务器根据此请求寻找资源并发送给客户。在这里 location可以重定向到任意URL，既然是浏览器重新发出了请求，则就没有什么request传递的概念了。在客户浏览器路径栏显示的是其重定向的路径，客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次访问请求。

重定向，其实是两次request:第一次，客户端request A,服务器响应，并response回来，告诉浏览器，你应该去B。这个时候IE可以看到地址变了，而且历史的回退按钮也亮了。重定向可以访问自己web应用以外的资源。在重定向的过程中，传输的信息会被丢失。

HTTP状态码301和302的区别，都有哪些用途？

官方的比较简洁的说明：
301 redirect: 301 代表永久性转移(Permanently Moved)
302 redirect: 302 代表暂时性转移(Temporarily Moved )
他俩都表示重定向

详细来说，301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。他们的不同在于。
301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了）；
302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B。

什么是重定向啊？
就是地址A跳转到地址B啦。百度百科的解释：重定向(Redirect)就是通过各种方法将各种网络请求重新定个方向转到其它位置（如：网页重定向、域名的重定向、路由选择的变化也是对数据报文经由路径的一种重定向）。

可是，为什么要进行重定向啊？什么时候需要重定向呢？

网站调整（如改变网页目录结构）
网页被移到一个新地址；
网页扩展名改变(如应用需要把.php改成.Html或.shtml)

这种情况下，如果不做重定向，则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个404页面错误信息，访问流量白白丧失；再者某些注册了多个域名的网站，也需要通过重定向让访问这些域名的用户自动跳转到主站点等。

那么，什么时候进行301或者302跳转呢？

使用301跳转的场景：

域名到期不想续费（或者发现了更适合网站的域名），想换个域名
空间服务器不稳定，换空间的时候

使用302的场景：
当一个网站或者网页24—48小时内临时移动到一个新的位置，这时候就要进行302跳转

HTTPS 的工作过程？

1、客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了；
2、服务器从中选出一套加密算法和 hash 算法以及自己的身份信息（地址等）以证书的形式发送给浏览器，证书中包含服务器信息，加密公钥，证书的办法机构；
3、客户端收到网站的证书之后要做下面的事情：

验证证书的合法性
果验证通过证书，浏览器会生成一串随机数，并用证书中的公钥进行加密
用约定好的 hash 算法计算握手消息，然后用生成的密钥进行加密，然后一起发送给服务器

4、服务器接收到客户端传送来的信息，要做下面的事情：

4.1 用私钥解析出密码，用密码解析握手消息，验证 hash 值是否和浏览器发来的一致；
4.2 使用密钥加密消息；

5、如果计算法 hash 值一致，握手成功。

HTTPS 的优缺点？

优点：

使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性；
HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：

HTTPS 协议握手阶段比较费时
HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；
SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；
HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

HTTP 和 HTTPS 的区别？

开销：HTTPS 协议需要到 CA 申请证书，一般免费证书很少，需要交费；
资源消耗：HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议，需要消耗更多的 CPU 和内存资源；
端口不同：HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443；
安全性：HTTP 的连接很简单，是无状态的；HTTPS 协议是由 TSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全

什么是数字签名？

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

什么是数字证书？

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的.