Java工程师面试题-计算机网络

发表于 更新于 阅读次数： 本文字数： 59k 阅读时长 ≈ 54 分钟
面试题60道

推荐先阅读：Java工程师面试题

请介绍七层网络体系结构。

参考回答

  1. 为什么分七层

    支持异构网络的互联互通。

  2. 七层分别负责的内容（功能）

    OSI 模型把网络通信的工作分为 7 层，从下到上分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

    (1) 物理层

    任务：透明地传输比特流。

    功能：为数据段设备提供传送数据通路

    传输单位：比特

    所实现的硬件：集线器，中继器

    （2）数据链路层

    任务：将网络层传输下来的IP数据报组装成帧

    功能：a. 链路连接的建立、拆除和分离

        b. 帧定界和帧同步

    c.差错检测

    传输单位：帧

    所实现的硬件：交换机、网桥

    协议：PPP,HDLC、SDLC、STP、ARQ

    (3)网络层

    任务：a. 将传输层传下来的报文段封装成分组

        b.选择合适的路由，使得传输层传下来的分组能够交付到目的主机

    功能：a. 为传输层提供服务

        b. 组包和拆包

    c. 路由选择

    d.拥塞控制

    传输单位：数据段

    所实现的硬件：路由器

    协议：ICMP、ARP、RARP、IP、IGMP、OSPF

    (4)传输层

    任务：负责主机中两个进程之间的通信

    功能：

      a. 为端到端连接提供可靠的服务

  b. 为端到端连接提供流量控制、差错控制、服务质量等管理服务

    传输单位：报文段（TCP）或用户数据报（UDP）

    协议：TCP、UDP

    (5)会话层

    任务：不同主机上各进程间的对话

    功能：管理主机间的会话进程，包括建立、管理以及终止进程间的会话。是一种端到端的服务

    (6)表示层

    负责处理在两个内部数据表示结构不同的通信系统之间交换信息的表示格式，为数据加密和解密以及为提高传输效率提供必需的数据压缩以及解压等功能。

    (7)应用层

    任务：提供系统与用户的接口

    功能：

      a.文件传输

  b. 访问和管理

  c. 电子邮件服务

    协议：FTP、SMTP、POP3、HTTP、DNS、TELnet

请介绍五层网络体系结构。

参考回答

五层网络体系结构分分别为：应用层、运输层、网络层、数据链路层、物理层。各层功能分别如下：

  1. 第五层——应用层(application layer)

    (1) 应用层(application layer)：是体系结构中的最高。直接为用户的应用进程提供服务。

    (2) 在因特网中的应用层协议很多，如支持万维网应用的HTTP协议，支持电子邮件的SMTP协议，支持文件传送的FTP协议等等。

  2. 第四层——运输层(transport layer)

    (1) 运输层(transport layer)：负责向两个主机中进程之间的通信提供服务。由于一个主机可同时运行多个进程，因此运输层有复用和分用的功能。

    a. 复用，就是多个应用层进程可同时使用下面运输层的服务。

    b. 分用，就是把收到的信息分别交付给上面应用层中相应的进程。

    (2) 运输层主要使用以下两种协议： (1) 传输控制协议TCP(Transmission Control Protocol)：面向连接的，数据传输的单位是报文段，能够提供可靠的交付。 (2) 用户数据包协议UDP(User Datagram Protocol)：无连接的，数据传输的单位是用户数据报，不保证提供可靠的交付，只能提供“尽最大努力交付”。

  3. 第三层——网络层(network layer)

    网络层(network layer)主要包括以下两个任务：

    (1) 负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把运输层残生的报文段或用户数据报封装成分组或包进行传送。在TCP/IP体系中，由于网络层使用IP协议，因此分组也叫做IP数据报，或简称为数据报。

    (2) 选中合适的路由，使源主机运输层所传下来的分组，能够通过网络中的路由器找到目的主机。

  4. 第二层——数据链路层(data link layer)

    数据链路层(data link layer)：常简称为链路层，我们知道，两个主机之间的数据传输，总是在一段一段的链路上传送的，也就是说，在两个相邻结点之间传送数据是直接传送的(点对点)，这时就需要使用专门的链路层的协议。

    在两个相邻结点之间传送数据时，数据链路层将网络层交下来的IP数据报组装成帧(framing)，在两个相邻结点之间的链路上“透明”地传送帧中的数据。

    每一帧包括数据和必要的控制信息(如同步信息、地址信息、差错控制等)。典型的帧长是几百字节到一千多字节。

    注意：”透明”是一个很重要的术语。它表示，某一个实际存在的事物看起来却好像不存在一样。”在数据链路层透明传送数据”表示无力什么样的比特组合的数据都能够通过这个数据链路层。因此，对所传送的数据来说，这些数据就“看不见”数据链路层。或者说，数据链路层对这些数据来说是透明的。 (1) 在接收数据时，控制信息使接收端能知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提取出数据部分，上交给网络层。 (2) 控制信息还使接收端能检测到所收到的帧中有无差错。如发现有差错，数据链路层就简单地丢弃这个出了差错的帧，以免继续传送下去白白浪费网络资源。如需改正错误，就由运输层的TCP协议来完成。

  5. 第一层——物理层(physical layer)

    物理层(physical layer)：在物理层上所传数据的单位是比特。物理层的任务就是透明地传送比特流。

了解网络编程协议吗？客户端发送给服务器的请求，怎么确定具体的协议？

参考回答

了解，客户端发送给服务器端的请求，可以根据统一资源定位系统（uniform resource locator，URL）来确定具体使用的协议。

答案解析

一个完整的URL包括–协议部分、网址、文件地址部分。协议部分以//为分隔符，在interner中，我们可以使用多种协议：

HTTP——HyperText Transfer Protocol（超文本传输协议）

FTP——File Transfer Protocol（文件传输协议）

Gopher——The Internet Gopher Protocol(网际Gopher协议)

File——本地文件传输协议

HTTPS——安全套接字层超文本传输协议(http的安全版)

例如百度网址：http://baidu.com，可以看出使用的是http协议。

TCP、HTTP、FTP分别属于哪一层？

参考回答

TCP、HTTP、FTP分别属于传输层、应用层、应用层。

答案解析

  1. TCP协议简介

    （1）TCP协议的特性

    TCP是面向连接的，提供全双工的服务，数据流可以双向传输。也是点对点的，即在单个发送放方和单个接收方之间的连接。

    （2）TCP 报文段结构

    序号：TCP 的序号是数据流中的字节数，不是分组的序号。表示该报文段数据字段首字节的序号。

    确认号：TCP 使用累积确认，确认号是第一个未收到的字节序号，表示希望接收到的下一个字节。

    首部长度：通常选项字段为空，所以一般 TCP 首部的长度是 20 字节。

    选项字段(可选与变长的)：用于发送方与接收方协商 MSS(最大报文段长)，或在高速网络环境下用作窗口

    调节因子。

    标志字段

    **ACK**：指示确认字段中的值是有效的
 
**RST,SYN,FIN**：连接建立与拆除
 
**PSH**：指示接收方应立即将数据交给上层
 
**URG**：报文段中存在着(被发送方的上层实体置位)“紧急”的数据

    接收窗口：用于流量控制（表示接收方还有多少可用的缓存空间）。

    TCP RFC 并没有规定失序到达的分组应该如何处理，而是交给程序员。可以选择丢弃或保留。如果发生超时，TCP 只重传第一个已发送而未确认的分组，超时时间间隔会设置为原来的 2 倍。

    （3）流量控制

    如果应用程序读取数据相当慢，而发送方发送数据太多、太快，会很容易使接收方的接收缓存溢出，流量控制就是用来进行发送速度和接收速度的匹配。发送方维护一个“接收窗口”变量，这个变量表示接收方当前可用的缓存空间。

  2. HTTP（超文本传输协议）简介

    （1）HTTP协议的特性

    HTTP 协议一共有五大特点：a. 支持客户/服务器模式；b. 简单快速；c. 灵活；d. 无连接；e. 无状态。

    无连接含义：限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

    无状态含义：指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。

    （2）HTTP 客户机及服务器

    HTTP 客户机：web 浏览器

    HTTP 服务器：web 服务器，包含 web 对象（HTML 文件、JPEG 文件、java 小程序、视频片段等）

    （3）HTTP 方法字段：

    GET：绝大部分 HTTP 请求报文使用 GET 方法

    POST：用户提交表单时（如向搜索引擎提供关键字），但提交表单不一定要用 POST 方法

    HEAD：类似于 GET，区别在于服务器返回的响应报文中不包含请求对象（常用于故障跟踪）

    PUT：用于向服务器上传对象

    DELETE：用于删除服务器上的对象

    （4）HTTP 状态信息

    301 Permanently Moved 被请求的资源已永久移动到新位置，新的URL在Location头中给出，浏览器应该自动地访问新的URL。

    302 Found 请求的资源现在临时从不同的URL响应请求。301是永久重定向，而302是临时重定向。

    200 OK 表示从客户端发来的请求在服务器端被正确处理

    304 Not Modified 304状态码是告诉浏览器可以从缓存中获取所请求的资源。

    400 bad request 请求报文存在语法错误

    403 forbidden 表示对请求资源的访问被服务器拒绝

    404 not found 表示在服务器上没有找到请求的资源

    500 internal sever error 表示服务器端在执行请求时发生了错误

    503 service unavailable 表明服务器暂时处于超负载或正在停机维护，无法处理请求

    （4）HTTP中常见的文件格式

    text/html： HTML格式

    text/plain：纯文本格式

    image/jpeg：jpg图片格式

    application/json： JSON数据格式

    application/x-www-form-urlencoded： form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据格式）

    multipart/form-data： 在表单中进行文件上传时使用

  3. FTP（文件传输协议简介)

    FTP 使用两个并行的 TCP 连接来传输文件：

    （1）控制连接（持久）：传输控制信息，如用户标识、口令、改变远程目录命令、文件获取上传的命令；

    （2）数据连接（非持久）：传输实际文件。

    FTP 客户机发起向 FTP 服务器的控制连接，然后在该连接上发送用户标识和口令、改变远程目录的命令。FTP服务器收到命令后，发起一个到客户机的数据连接，在该连接上准确地传送一个文件并关闭连接。

    有状态的协议：FTP 服务器在整个会话期间保留用户的状态信息。服务器必须把特定的用户账号和控制连接

    联系起来。

  4. 传输层简介

    （1）传输层的服务基本原理

    a. 多路复用和解复用（分路）技术
 
  **复用：**发送方的不同的应用进程都可以使用同一个传输层协议传送数据；
 
  **分路技术**：接收方的传输层剥去报文首部之后能把这些数据正确的传输到正确的应用进程上。
 
b. 可靠数据传输
 
c. 流量控制和拥塞控制

    （2）传输层提供的服务

    a. 传输层寻址和端口
 
端口号就是用来标识应用进程的数字标识。其端口号的长度为16Bit;也就是能够标识2^16个不同的端口号。另外端口号根据端口范围分为2类。分别为**服务端使用的端口号（熟知端口号数值范围：0-1023；登记端口号数值范围：1024-49151）**和**客户端使用的端口号（数值范围为49152-65535）**。常见端口号如下：
 
    **FTP**：21
 
    **TELNET**：23
 
    **SMTP**：25
 
    **DNS**：53
 
    **TFTP**：69
 
    **HTTP**：80
 
    **SNMP**：161
 
b. 无连接服务和面向连接服务

    （3）流量控制和拥塞控制

    a. **流量控制：**如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。
 
b. **拥塞控制：**拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
 
两者的区别：流量控制是为了预防拥塞。如：在马路上行车，交警跟红绿灯是流量控制，当发生拥塞时，如何进行疏散，是拥塞控制。流量控制指点对点通信量的控制。而拥塞控制是全局性的，涉及到所有的主机和降低网络性能的因素。

  5. 应用层简介

    应用层的具体内容就是规定应用进程在通信时所遵循的协议。应用层协议分类如下：

    (1). 域名系统(Domain Name System，DNS)：用于实现网络设备名字到IP地址映射的网络服务。

    (2). 文件传输协议(File Transfer Protocol，FTP)：用于实现交互式文件传输功能。

    (3). 简单邮件传送协议(Simple Mail Transfer Protocol, SMTP)：用于实现电子邮箱传送功能

    (4). 超文本传输协议(HyperText Transfer Protocol，HTTP)：用于实现WWW服务。

    (5). 简单网络管理协议(simple Network Management Protocol，SNMP)：用于管理与监视网络设备。

    (6). 远程登录协议(Telnet)：用于实现远程登录功能。

讲一下TCP/IP协议。

参考回答

  1. TCP/IP协议定义

    TCP/IP（Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议）是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP协议不仅仅指的是TCP和IP两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇， 只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。

  2. TCP/IP协议组成

    TCP/IP结构模型分为应用层、传输层、网络层、链路层（网络接口层）四层，以下是各层的详细介绍：

    （1）应用层

    应用层是TCP/IP协议的第一层，是直接为应用进程提供服务的。

    a. 对不同种类的应用程序它们会根据自己的需要来使用应用层的不同协议，邮件传输应用使用了SMTP协议、万维网应用使用了HTTP协议、远程登录服务应用使用了有TELNET协议。

    b. 应用层还能加密、解密、格式化数据。

    c. 应用层可以建立或解除与其他节点的联系，这样可以充分节省网络资源。

    （2）传输层

    作为TCP/IP协议的第二层，运输层在整个TCP/IP协议中起到了中流砥柱的作用。且在运输层中，TCP和UDP也同样起到了中流砥柱的作用。

    （3）网络层

    网络层在TCP/IP协议中的位于第三层。在TCP/IP协议中网络层可以进行网络连接的建立和终止以及IP地址的寻找等功能。

    （4）链路层（网络接口层）

    在TCP/IP协议中，网络接口层位于第四层。由于网络接口层兼并了物理层和数据链路层。所以，网络接口层既是传输数据的物理媒介，也可以为网络层提供一条准确无误的线路。

  3. TCP/IP协议特点

    TCP/IP协议能够迅速发展起来并成为事实上的标准，是它恰好适应了世界范围内数据通信的需要。它有以下特点：

    （1）协议标准是完全开放的，可以供用户免费使用，并且独立于特定的计算机硬件与操作系统；

    （2）独立于网络硬件系统，可以运行在广域网，更适合于互联网；

    （3）网络地址统一分配，网络中每一设备和终端都具有一个唯一地址；

    （4）高层协议标准化，可以提供多种多样可靠网络服务。

说一说你对ARP协议的理解。

参考回答

ARP协议即地址解析协议，是根据IP地址获取MAC地址的一个网络层协议。

  1. 工作原理

    ARP首先会发起一个请求数据包，数据包的首部包含了目标主机的IP地址，然后这个数据包会在链路层进行再次包装，生成以太网数据包，最终由以太网广播给子网内的所有主机，每一台主机都会接收到这个数据包，并取出标头里的IP地址，然后和自己的IP地址进行比较，如果相同就返回自己的MAC地址，如果不同就丢弃该数据包。ARP接收返回消息，以此确定目标机的MAC地址；与此同时，ARP还会将返回的MAC地址与对应的IP地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。

  2. 工作过程

    主机A的IP地址为192.168.1.1，MAC地址为0A-11-22-33-44-01；

    主机B的IP地址为192.168.1.2，MAC地址为0A-11-22-33-44-02；

    当主机A要与主机B通信时，地址解析协议可以将主机B的IP地址（192.168.1.2）解析成主机B的MAC地址，以下为工作流程：

    第1步：根据主机A上的路由表内容，IP确定用于访问主机B的转发IP地址是192.168.1.2。然后A主机在自己的本地ARP缓存中检查主机B的匹配MAC地址。

    第2步：如果主机A在ARP缓存中没有找到映射，它将询问192.168.1.2的硬件地址，从而将ARP请求帧广播到本地网络上的所有主机。源主机A的IP地址和MAC地址都包括在ARP请求中。本地网络上的每台主机都接收到ARP请求并且检查是否与自己的IP地址匹配。如果主机发现请求的IP地址与自己的IP地址不匹配，它将丢弃ARP请求。

    第3步：主机B确定ARP请求中的IP地址与自己的IP地址匹配，则将主机A的IP地址和MAC地址映射添加到本地ARP缓存中。

    第4步：主机B将包含其MAC地址的ARP回复消息直接发送回主机A。

    第5步：当主机A收到从主机B发来的ARP回复消息时，会用主机B的IP和MAC地址映射更新ARP缓存。本机缓存是有生存期的，生存期结束后，将再次重复上面的过程。主机B的MAC地址一旦确定，主机A就能向主机B发送IP通信了。

  3. ARP报文格式

硬件类型：指明了发送方想知道的硬件接口类型，以太网的值为1；

协议类型：指明了发送方提供的高层协议类型，IP为0800（16进制）；

硬件地址长度和协议长度：指明了硬件地址和高层协议地址的长度，这样ARP报文就可以在任意硬件和任意协议的网络中使用；

操作类型：用来表示这个报文的类型，ARP请求为1，ARP响应为2，RARP请求为3，RARP响应为4；

发送方硬件地址（0-3字节）：源主机硬件地址的前3个字节；

发送方硬件地址（4-5字节）：源主机硬件地址的后3个字节；

发送方IP地址（0-1字节）：源主机硬件地址的前2个字节；

发送方IP地址（2-3字节）：源主机硬件地址的后2个字节；

目标硬件地址（0-1字节）：目的主机硬件地址的前2个字节；

目标硬件地址（2-5字节）：目的主机硬件地址的后4个字节；

目标IP地址（0-3字节）：目的主机的IP地址。

IP协议包含哪些字段？

参考回答

IP所包含字段结构图如下：

img

**IP协议包含字段如下：**

**4位版本号：**指定IP协议的版本，对于IPv4来说就是4

**4位头部长度：**IP头部长度有多少个4字节，所以头部最大长度就是15*4=60字节

**8位服务类型：**3位优先权(已弃用)，4位TOS字段，1位保留字段(必须设置为0)。4为TOS为：最小延时，最大吞吐量，最高可靠性，最小成本，这四个只能选择一个

**16位总长度：**IP数据报整体占多少字节

**16为标识：**唯一的标识主机发送的报文，IP报文在数据链路层被分片，那么每一个片中的标识都是相同的

**3位标志字段：**第一位保留，第二位置1表示进制分片(报文长度超过MTU，丢弃报文)，第三位更多分片，最后一个分片是1，其他是0

**13位分片偏移：**相对于原始IP报文开始处的偏移

**8位生存时间：**数据报到达目的地的最大报文跳数，每经过一个路由，TTL-=1，一直到0都没有到达目的地，报文丢弃。

**8位协议**：表示上层协议类型，把IP交给TCP还是UDP，其中ICMP是1，TCP是6，UDP是17

**16位头部校验和：**使用CRC校验，鉴别头部是否损坏

**32位源地址和32位目标地址：**表示发送端和接收端

应用层都包含什么协议？

参考回答

应用层包含的协议有DNS、FTP、SMTP、HTTP、SNMP、Telnet等，其作用分别如下：

  1. **域名系统(Domain Name System，DNS)**：用于实现网络设备名字到IP地址映射的网络服务。
  2. **文件传输协议(File Transfer Protocol，FTP)**：用于实现交互式文件传输功能。
  3. **简单邮件传送协议(Simple Mail Transfer Protocol, SMTP)**：用于实现电子邮箱传送功能。
  4. **超文本传输协议(HyperText Transfer Protocol，HTTP)**：用于实现WWW服务。
  5. **简单网络管理协议(simple Network Management Protocol，SNMP)**：用于管理与监视网络设备。
  6. **远程登录协议(Telnet)**：用于实现远程登录功能。

答案解析

应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递消息。特别是定义了:

  1. 交换的消息类型，如请求消息和响应消息。
  2. 各种消息类型的语法，如消息中的各个字段及其详细描述。
  3. 字段的语义，即包含在字段中的信息的含义。
  4. 进程何时、如何发送消息及对消息进行响应的规则。
  5. 有些应用层协议是由RFC文档定义的，因此它们位于公共领域，例如HTTP。
  6. 有些应用层协议是公司或者个人私有的，位于私人领域，例如QQ。

应用层报文怎么传输到另一个应用层？

参考回答

应用层数据（报文）向外发送时，数据是由最上面的应用层向下经过一层层封装后发送给物理层；而接收数据时，数据是由物理层向上经过一层层解封后发给应用层。数据的封装和解封过程如下:

  1. 数据的封装过程简介

    传输层及其以下的机制由内核提供， 应用层由用户进程提供， 应用程序对通讯数据的含义进行解释， 而传输层及其以下处理通讯的细节，将数据从一台计算机通过一定的路径发送到另一台计算机。 应用层数据通过协议栈发到网络上时，每层协议都要加上一个相对应的头部（header ），该过程称为封装封装过程如下图所示：

  1. 数据的解封过程简介

    不 同 的 协 议 层 对 数 据 包 有 不 同的 称 谓 ，在 传 输 层 叫 做 段（segment ），在网络层叫做数据报（ datagram) ，在链路层叫做帧（frame ）。数据封装成帧后发到传输介质上，到达目的主机后，每层协议再剥掉相应的头部，最后将应用层数据交给应用程序处理，该过程称为解封。解封过程如下图所示：

    img

  2. 举例说明数据封装和解封装过程

    （1）从计算机 A 的应用层内网通软件向计算机 B 发出一个消息，生成数据；

    （2）请求从计算机 A 的应用层下到 计算机A 的传输层，传输层在上层数据前面加上 TCP报头，报头中包括目标端口以及源端口；

    （3）传输层数据下到网络层，计算机A 在网络层封装，源 IP地址为 计算机A地址，目标 IP地址为 计算机 B 地址；

    （4）计算机 A 将计算机B 的 IP 地址和子网掩码与自己做比对，可以发现 计算机 B 与自己处于相同的子网。所以数据传输不必经过网关设备；

    （5）数据包下到 计算机 A 的数据链路层进行封装，源 MAC 地址为 计算机A的 MAC地址，目标 MAC 地址查询自己的 ARP 表。

    （6）计算机 A 把帧转换成 bit 流，从物理接口网卡发出；

    （7）物理层接收到电信号，把它交给数据链路层进行查看帧的目标 MAC 地址，和自己是否相等，如果相等说明该帧是发送给自己的，于是将MAC帧头解开并接着上传到网络层；

    （8）网络层查看目标 IP 地址和自己是否匹配，如果匹配即解开 IP 头封装。然后再把数据上传到传输层；

    （9）传输层解开对应的包头之后，继续把数据传给应用层，计算机 B 即可接收到计算机 A 发的消息。

答案解析

报文、报文段、分组、包、数据报、帧、数据流的概念区别如下：

  1. 报文（message）

    我们将位于应用层的信息分组称为报文。报文是网络中交换与传输的数据单元，也是网络传输的单元。报文包含了将要发送的完整的数据信息，其长短不需一致。报文在传输过程中会不断地封装成分组、包、帧来传输，封装的方式就是添加一些控制信息组成的首部，那些就是报文头。

  2. 报文段（segment）

    通常是指起始点和目的地都是传输层的信息单元。

  3. 分组/包（packet）

    分组是在网络中传输的二进制格式的单元，为了提供通信性能和可靠性，每个用户发送的数据会被分成多个更小的部分。在每个部分的前面加上一些必要的控制信息组成的首部，有时也会加上尾部，就构成了一个分组。它的起始和目的地是网络层。

  4. 数据报（datagram）

    面向无连接的数据传输，其工作过程类似于报文交换。采用数据报方式传输时，被传输的分组称为数据报。通常是指起始点和目的地都使用无连接网络服务的的网络层的信息单元。

  5. 帧（frame）

    帧是数据链路层的传输单元。它将上层传入的数据添加一个头部和尾部，组成了帧。它的起始点和目的点都是数据链路层。

  6. 数据单元（data unit）

    指许多信息单元。常用的数据单元有服务数据单元（SDU）、协议数据单元（PDU）。

    SDU是在同一机器上的两层之间传送信息。PDU是发送机器上每层的信息发送到接收机器上的相应层（同等层间交流用的）。

介绍一下tcp的三次握手。

参考回答

img

  1. 第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
  2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
  3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

介绍一下tcp的四次挥手。

参考回答

img

  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连接的时间要比客户端早一些。

为什么需要四次挥手？

参考回答

  1. 四次挥手示意图

    img

  2. 四次挥手过程

    （1）客户端向服务器发送FIN控制报文段（首部中的 FIN 比特被置位）；

    （2）服务端收到FIN，回复ACK。服务器进入关闭等待状态，发送FIN;

    （3）客户端收到FIN，给服务器回复ACK，客户端进入等待状态（进入“等待”，以确保服务器收到ACK真正关闭连接）;

    （4）服务端收到ACK，链接关闭。

  3. 四次挥手原因

    TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当客户端发出FIN报文段时，只是表示客户端已经没有数据要发送了，客户端告诉服务器，它的数据已经全部发送完毕了；但是，这个时候客户端还是可以接受来自服务端的数据；当服务端返回ACK报文段时，表示它已经知道客户端没有数据发送了，但是服务端还是可以发送数据到客户端的；当服务端也发送了FIN报文段时，这个时候就表示服务端也没有数据要发送了，就会告诉客户端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

    简单地说，前 2 次挥手用于关闭一个方向的数据通道，后两次挥手用于关闭另外一个方向的数据通道。

为什么要有最后一次ACK？

参考回答

  1. 三次握手示意图

    img

  2. 四次挥手过程

    （1）客户端发送一个SYN0给服务器（选择初始序列号，不携带任何数据）

    （2）服务器收到SYN0，回复SYN1和ACK（服务器分配缓存，选择自己初始序列号）

    （3）客户端收到SYN1、ACK，回复ACK（可以包含数据）

  3. 为什么要有最后一次ACK

    客户端首先向服务器发送一个连接请求，但是可能这个连接请求走了远路，等了很长时间，服务器都没有收到，那么客户端可能会再次发送，此时服务器端收到并且回复SYN、ACK；在这个时候最先发送的那个连接请求到达服务器，那么服务器会回复一个SYN，ACK；但是客户端表示自己已经收到确认了，并不搭理这个回复，那么服务器可能陷入等待，如果这种情况多了，那么会导致服务器瘫痪，所以要发送第三个确认。

介绍一下tcp粘包、拆包的机制。

参考回答

  1. TCP粘包和拆包问题

    TCP是一个“流”协议，所谓流，就是没有界限的一长串二进制数据。TCP作为传输层协议并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

  2. 产生TCP粘包和拆包的原因

    我们知道TCP是以流动的方式传输数据的，传输的最小单位为一个报文段（Segment）。TCP Header中有个Options标识位。常见的标识位为MSS（Maximum Segment Size）指的是，连接层每次传输的数据有个最大限制MTU（Maximum Transmission Unit），一般是1500bit，超过这个量要分成多个报文段，MSS则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460bit。换算成字节，也就是180多字节。 TCP为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了以后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制来接受数据。 发生TCP粘包、拆包主要是以下原因： （1）应用程序写入数据大于套接字缓冲区大小，会发生拆包； （2）应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发送粘包； （3）进行MSS（最大报文长度）大小的TCP分段，当TCP报文长度——TCP header长度>MSS 的时候会发生拆包； （4）接收方法不及时读取套接字缓冲区数据，这将发生粘包。

  3. 如何处理粘包和拆包

    假设应用层协议是http

    我从浏览器中访问了一个网站，网站服务器给我发了200k的数据。建立连接的时候，通告的MSS是50k，所以为了防止ip层分片，tcp每次只会发送50k的数据，一共发了4个tcp数据包。如果我又访问了另一个网站，这个网站给我发了100k的数据，这次tcp会发出2个包，问题是，客户端收到6个包，怎么知道前4个包是一个页面，后两个是一个页面。既然是tcp将这些包分开了，那tcp会将这些包重组吗，它送给应用层的是什么？这是我自己想的一个场景，正式一点讲的话，这个现象叫拆包。

    我们再考虑一个问题。

    tcp中有一个negal算法，用途是这样的：通信两端有很多小的数据包要发送，虽然传送的数据很少，但是流程一点没少，也需要tcp的各种确认，校验。这样小的数据包如果很多，会造成网络资源很大的浪费，negal算法做了这样一件事，当来了一个很小的数据包，我不急于发送这个包，而是等来了更多的包，将这些小包组合成大包之后一并发送，不就提高了网络传输的效率的嘛。这个想法收到了很好的效果，但是我们想一下，如果是分属于两个不同页面的包，被合并在了一起，那客户那边如何区分它们呢？这就是粘包问题。

    从粘包问题我们更可以看出为什么tcp被称为流协议，因为它就跟水流一样，是没有边界的，没有消息的边界保护机制，所以tcp只有流的概念，没有包的概念。

    我们还需要有两个概念：

    （1）长连接： Client方与Server方先建立通讯连接，连接建立后不断开， 然后再进行报文发送和接收。 （2）短连接：Client方与Server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此种方式常用于一点对多点 通讯，比如多个Client连接一个Server。

    实际，我想象的关于粘包的场景是不对的，http连接是短连接，请求之后，收到回答，立马断开连接，不会出现粘包。 拆包现象是有可能存在的。

    处理拆包这里提供两种方法：

    （1）通过包头+包长+包体的协议形式，当服务器端获取到指定的包长时才说明获取完整。 （2） 指定包的结束标识，这样当我们获取到指定的标识时，说明包获取完整。

    处理粘包我们从上面的分析看到，虽然像http这样的短连接协议不会出现粘包的现象，但是一旦建立了长连接，粘包还是有可能会发生的。处理粘包的方法如下：

    （1）发送方对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。

    （2）接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，判断每条数据的长度的方法有两种：

    a. 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。

    b. 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

答案解析

扩展资料

UDP会不会产生粘包问题呢？

TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。

介绍一下TCP和UDP的区别。

参考回答

TCP和UDP有如下区别：

  1. 连接：TCP面向连接的传输层协议，即传输数据之前必须先建立好连接；UDP无连接。
  2. 服务对象：TCP点对点的两点间服务，即一条TCP连接只能有两个端点；UDP支持一对一，一对多，多对一，多对多的交互通信。
  3. 可靠性：TCP可靠交付：无差错，不丢失，不重复，按序到达；UDP尽最大努力交付，不保证可靠交付。
  4. 拥塞控制/流量控制：有拥塞控制和流量控制保证数据传输的安全性；UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。
  5. 报文长度：TCP动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的；UDP面向报文，不合并，不拆分，保留上面传下来报文的边界。
  6. 首部开销：TCP首部开销大，首部20个字节；UDP首部开销小，8字节（源端口，目的端口，数据长度，校验和）。
  7. 适用场景（由特性决定）：数据完整性需让位于通信实时性，则应该选用TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。

TCP和UDP对于网络稳定性有什么要求？

参考回答

  1. TCP优缺点

    优点：可靠、稳定

    TCP的可靠体现在TCP在传输数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完之后，还会断开连接用来节约系统资源。

    缺点：慢，效率低，占用系统资源高，易被攻击

    在传递数据之前要先建立连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞机制等都会消耗大量时间，而且要在每台设备上维护所有的传输连接。然而，每个链接都会占用系统的CPU、内存等硬件资源。因为TCP有确认机制、三次握手机制，这些也导致TCP容易被利用，实现DOS、DDOS、CC等攻击。

  2. UDP优缺点

    优点：快，比TCP稍安全

    UDP没有TCP拥有的各种机制，是一个无状态的传输协议，所以传递数据非常快，没有TCP的这些机制，被攻击利用的机制就少一些，但是也无法避免被攻击。

    缺点：不可靠，不稳定

    因为没有TCP的那些机制，UDP在传输数据时，如果网络质量不好，就会很容易丢包，造成数据的缺失。

  3. 适用场景（网络稳定性要求）

    TCP：当对网络通讯质量有要求时，比如HTTP、HTTPS、FTP等传输文件的协议， POP、SMTP等邮件传输的协议

    UDP：对网络通讯质量要求不高时，要求网络通讯速度要快的场景。

    所以，TCP对网络稳定性要求高，而UDP相对弱一些。

如何让UDP可靠一些？

参考回答

  1. 为什么需要可靠的UDP

    在弱网（2G、3G、信号不好）环境下，使用 TCP 连接的延迟很高，影响体验。使用 UDP 是很好的解决方案，既然把 UDP 作为弱网里面的 TCP 来使用，就必须保证数据传输能像 TCP 一样可靠

  2. 如何实现可靠的UDP

    UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。关键在于两点，从应用层角度考虑：

    （1）提供超时重传，能避免数据报丢失。

    （2）提供确认序列号，可以对数据报进行确认和排序。

    本端：首先在UDP数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算RTT(数据报传输的往返时间)，计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报，即收到对端的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时RTO扩大为原来的两倍，重新开始计时。

    对端：接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。

答案解析

扩展资料

  1. 已经实现的可靠UDP：

（1）RUDP 可靠数据报传输协议；

（2）RTP 实时传输协议

为数据提供了具有实时特征的端对端传送服务；

Eg：组播或单播网络服务下的交互式视频、音频或模拟数据

（3）UDT

 基于UDP的数据传输协议，是一种互联网传输协议；

主要目的是支持高速广域网上的海量数据传输，引入了新的拥塞控制和数据可靠性控制机制（互联网上的标准数据传输协议TCP在高带宽长距离的网络上性能很差）；

UDT是面向连接的双向的应用层协议，同时支持可靠的数据流传输和部分可靠的数据报服务；

应用：高速数据传输，点到点技术(P2P)，防火墙穿透，多媒体数据传输；

TCP报文首部中序号占多少字节？

参考回答

序号字段占4个字节（32位）。

答案解析

img

                                TCP首部字段详细图

TCP首部包括20字节的固定首部部分及长度可变的其他选项，所以TCP首部长度可变。20个字节又分为5部分，每部分4个字节32位，如图中的5行，每行表示32位。

  1. 源端口和目的端口字段——各占 2 字节（16位）。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。

  2. 序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。比如分组的第一个数据包由文件的14个字节数据组成，那么该数据包所添加的序号就是1，同理第二个数据包由文件的59个字节数据组成，那么该数据包所添加的序号就是5；

  3. 确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。比如接收端收到由文件14个字节数据+TCP首部组成的数据包后，删除首部提取14个字节数据，返回的确认号为5，即告诉发送端下一次应该发送文件的第5个字节及其之后字节组成的数据包过来。

  4. 数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远，也就是TCP首部的长度。“数据偏移”的单位是 32 位字（以 4 字节为计算单位），最大1111表示15x4=60个字节，即表示TCP首部最大长度为60个字节，因此“选项”部分最多40个字节。

  5. 保留字段——占 6 位，保留为今后使用，但目前应置为 0。

  6. 这里的六位二进制位，分别表示不同含义：

    （1）紧急 URG —— 当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。 即URG=1的数据包不用排队直接优先传输。

    （2）同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。即A想与B建立连接，发送过去的第一个数据包（第一次握手）中SYN=1；B返回的数据包（第二次握手）中SYN=1表示同意建立连接。

    （3）确认 ACK —— 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时，确认号无效。

  7. 窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。

  8. 检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。

  9. 紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。

  10. 选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”其他选项有：窗口扩大选项、时间戳选项、选择确认选项（SACK）。

  11. 填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

TCP中的缓存有什么作用？

参考回答

  1. TCP缓冲区是什么

    每个 socket 被创建后，都会分配两个缓冲区，输入缓冲区和输出缓冲区。

  2. 缓冲区的意义（作用）

    img

                                TCP套接字的I/O缓冲区示意图

    TCP的发送缓冲区是用来缓存应用程序的数据，发送缓冲区的每个字节都有序列号，被应答确认的序列号对应的数据会从发送缓冲区删除掉。

    write()/send() 并不立即向网络中传输数据，而是先将数据写入缓冲区中，再由TCP协议将数据从缓冲区发送到目标机器。一旦将数据写入到缓冲区，函数就可以成功返回，不管它们有没有到达目标机器，也不管它们何时被发送到网络，这些都是TCP协议负责的事情。 TCP协议独立于 write()/send() 函数，数据有可能刚被写入缓冲区就发送到网络，也可能在缓冲区中不断积压，多次写入的数据被一次性发送到网络，比如nagle算法，这取决于当时的网络情况、当前线程是否空闲等诸多因素，不由程序员控制。 read()/recv() 函数也是如此，也从输入缓冲区中读取数据，而不是直接从网络中读取。

  3. I/O缓冲区特性

    （1）I/O缓冲区在每个TCP套接字中单独存在；

    （2）I/O缓冲区在创建套接字时自动生成；

    （3）即使关闭套接字也会继续传送输出缓冲区中遗留的数据；

    （4）关闭套接字将丢失输入缓冲区中的数据。

    输入输出缓冲区的默认大小一般都是 8K，可以通过 getsockopt() 函数获取：

    //代码实例（缓冲区大小获取） 
    int servSock = socket(PF_INET, SOCK_STREAM, 0); 
    unsigned optVal; 
    int optLen = sizeof(int); 
    getsockopt(servSock, SOL_SOCKET, SO_SNDBUF, (char*)&optVal, &optLen); 
    /*  运行结果：  Buffer length: 8192  */

说一说TCP是怎么控制流量的？

参考回答

  1. 所谓流量控制就是让发送发送速率不要过快，让接收方来得及接收。

  2. TCP控制流量的方法

    利用滑动窗口机制就可以实施流量控制。

    原理就是运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。

    解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

答案解析

  1. TCP的滑动窗口

    为了提高信道的利用率TCP协议不使用停止等待协议，而是使用连续ARQ协议，意思就是可以连续发出若干个分组然后等待确认，而不是发送一个分组就停止并等待该分组的确认。

    TCP的两端都有发送/接收缓存和发送/接收窗口。TCP的缓存是一个循环队列，其中发送窗口可以用3个指针表示。而发送窗口的大小受TCP数据报中窗口大小的影响，TCP数据报中的窗口大小是接收端通知发送端其还可以接收多少数据，所以发送窗口根据接收的的窗口大小的值动态变化。

    以下的几张图片就帮助理解一下滑动窗口的机制：

    img

                    图1 根据B给出的窗口值，A构造出自己的发送窗口

    img

                                图2 A发送了11个字节的数据

    注意上图中的3个指针P1、P2、P3！此时接收窗口中接收的数据可能是失序的，但是也先存储在接收缓存之中。发送确认号的时候依然发送31，表示B期望接收的下一个数据报的标示符是31。

    img

                                图3 A收到新的确认号，发送窗口向前滑动

    img

                              图4 发送窗口内的序号都属于已经发送但未被确认

    如果发送窗口中的数据报都属于已发送但未被确认的话，那么A就不能再继续发送数据，而需要进行等待。

    img

                      图5 TCP的发送缓存和发送窗口（a）与接收缓存和接收窗口（b）

  2. 传输效率及Nagle算法

    TCP的数据传输分为交互数据流和成块数据流，交互数据流一般是一些交互式应用程序的命令，所以这些数据很小，而考虑到TCP报头和IP报头的总和就有40字节，如果数据量很小的话，那么网络的利用效率就较低。

    数据传输使用Nagle算法，Nagle算法很简单，就是规定一个TCP连接最多只能有一个未被确认的未完成的小分组。在该分组的确认到达之前不能发送其他的小分组。

    但是也要考虑另一个问题，叫做糊涂窗口综合症。当接收方的缓存已满的时候，交互应用程序一次只从缓存中读取一个字节（这时候缓存中腾出一个字节），然后向发送方发送确认信息，此时发送方再发送一个字节（收到的窗口大小为1），这样网络的效率很低。

    要解决这个问题，可以让接收方等待一段时间，使得接收缓存已有最够的空间容纳一个最长报文段，或者等到接收缓存已有一半的空间。只要这两种情况出现一种，就发送确认报文，同时发送方可以把数据积累成大的报文段发送。

HTTP2.0中TCP阻塞了怎么办？

参考回答

HTTP2.0中TCP阻塞了有如下两种方法可以解决：

（1）并发TCP连接（浏览器一个域名采用6-8个TCP连接，并发HTTP请求） （2）域名分片（多个域名，可以建立更多的TCP连接，从而提高HTTP请求的并发）

答案解析

1. TCP队头阻塞

TCP数据包是有序传输，中间一个数据包丢失，会等待该数据包重传，造成后面的数据包的阻塞。

2. HTTP队头阻塞

http队头阻塞和TCP队头阻塞完全不是一回事。

http1.x采用长连接(Connection:keep-alive)，可以在一个TCP请求上，发送多个http请求。

有非管道化和管道化，两种方式。

**非管道化**，完全串行执行，请求->响应->请求->响应...，后一个请求必须在前一个响应之后发送。

**管道化**，请求可以并行发出，但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是，没有序号标明顺序，只能串行接收。

**管道化请求的致命弱点**:

（1）会造成队头阻塞，前一个响应未及时返回，后面的响应被阻塞 （2）请求必须是幂等请求，不能修改资源。因为，意外中断时候，客户端需要把未收到响应的请求重发，非幂等请求，会造成资源破坏。

由于这个原因，目前大部分浏览器和Web服务器，都关闭了管道化，采用非管道化模式。

无论是非管道化还是管道化，都会造成队头阻塞(请求阻塞)。

解决http队头阻塞的方法：

（1）并发TCP连接（浏览器一个域名采用6-8个TCP连接，并发HTTP请求） （2）域名分片（多个域名，可以建立更多的TCP连接，从而提高HTTP请求的并发）

2. HTTP2方式

http2使用一个域名单一TCP连接发送请求，请求包被二进制分帧，不同请求可以互相穿插，避免了http层面的请求队头阻塞。 但是不能避免TCP层面的队头阻塞。

TCP如何保证可靠性？

参考回答

TCP协议保证数据传输可靠性的方式主要有：校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制。

  1. 校验和

    计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。 发送方：在发送数据之前计算检验和，并进行校验和的填充。 接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。

    img

    注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。

  2. 序列号和确认应答

    序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。 确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

    img

    序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。

  3. 超时重传

    在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？而没有收到ACK报文的原因可能是什么呢？

    首先，发送方没有接收到响应的ACK报文原因可能有两点：

    （1）数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。

    （2）接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。

    TCP在解决这个问题的时候引入了一个新的机制，叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。如果是刚才第一个原因，接收方收到二次重发的数据后，便进行ACK应答。如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。

  4. 连接管理

    连接管理就是三次握手与四次挥手的过程，保证可靠的连接，是保证可靠性的前提。

  5. 流量控制

    收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。

    在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。

  6. 拥塞控制

    TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。

    所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。

    拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。

    拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。

答案解析

无

说一说TCP里的reset状态。

参考回答

  1. TCP异常终止（reset报文）

    TCP的异常终止是相对于正常释放TCP连接的过程而言的，我们都知道，TCP连接的建立是通过三次握手完成的，而TCP正常释放连接是通过四次挥手来完成，但是有些情况下，TCP在交互的过程中会出现一些意想不到的情况，导致TCP无法按照正常的四次挥手来释放连接，如果此时不通过其他的方式来释放TCP连接的话，这个TCP连接将会一直存在，占用系统的部分资源。在这种情况下，我们就需要有一种能够释放TCP连接的机制，这种机制就是TCP的reset报文。reset报文是指TCP报头的标志字段中的reset位置一的报文。

  2. RST标志位（Reset）

    RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。就像上面说的一样，发送RST包关闭连接时，不必等缓冲区的包都发出去（不像上面的FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。

    TCP处理程序会在自己认为的异常时刻发送RST包。例如，A向B发起连接，但B之上并未监听相应的端口，这时B操作系统上的TCP处理程序会发RST包。

    又比如，AB正常建立连接了，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，网断了，A通过若干原因放弃了这个连接（例如进程重启）。网通了后，B又开始发数据包，A收到后表示压力很大，不知道这野连接哪来的，就发了个RST包强制把连接关了，B收到后会出现connect reset by peer错误。

答案解析

  1. TCP异常终止的常见情形

    （1）客户端尝试与服务器未对外提供服务的端口建立TCP连接，服务器将会直接向客户端发送reset报文。

    （2）客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送TCP reset报文，告之对方释放相关的TCP连接。

    （3）接收端收到TCP报文，但是发现该TCP的报文，并不在其已建立的TCP连接列表内，则其直接向对端发送reset报文。

    （4）在交互的双方中的某一方长期未收到来自对方的确认报文，则其在超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接。

    （5）有些应用开发者在设计应用系统时，会利用reset报文快速释放已经完成数据交互的TCP连接，以提高业务交互的效率。

如何利用UDP实现可靠传输？

参考回答

  1. 实现方法：

    （1）将实现放到应用层，然后类似于TCP，实现确认机制、重传机制和窗口确认机制；

    （2）给数据包进行编号，按顺序接收并存储，接收端收到数据包后发送确认信息给发送端，发送端接收到确认信息后继续发送，若接收端接收的数据不是期望的顺序编号，则要求重发；（主要解决丢包和包无序的问题）

  2. 已经实现的可靠UDP：

    （1）RUDP 可靠数据报传输协议；

    （2）RTP 实时传输协议

    为数据提供了具有实时特征的端对端传送服务；例如：组播或单播网络服务下的交互式视频、音频或模拟数据。

    （3）UDT

    基于UDP的数据传输协议，是一种互联网传输协议； 主要目的是支持高速广域网上的海量数据传输，引入了新的拥塞控制和数据可靠性控制机制（互联网上的标准数据传输协议TCP在高带宽长距离的网络上性能很差）；

UDT是面向连接的双向的应用层协议，同时支持可靠的数据流传输和部分可靠的数据报服务；

应用：高速数据传输，点到点技术(P2P)，防火墙穿透，多媒体数据传输；

答案解析

无

报文乱序怎么办？

参考回答

数据包会因为IP层所规划的路由链路的不同导致数据包的接收顺序与发送顺序会有所不同。另外因为TCP是一种全双工的协议，乱序可能发生在正向链路，也可能发生在反向链路，这两种不同的情况给TCP带来的影响也会略有差异。

  1. 正向链路乱序

    此时TCP会无法判断是数据包丢失还是乱序，因为丢包和乱序都会导致接收端收到次序混乱的数据包，造成接收端的数据空洞。TCP会将这种情况暂定为数据包的乱序，因为乱序是时间问题（可能是数据包的迟到），而丢包则意味着重传。当TCP意识到包出现乱序的情况时，会立即ACK，该ACK的TSER部分包含的TSEV值会记录当前接收端收到有序报文段的时刻。这会使得数据包的RTT样本值增大，进一步导致RTO时间延长。这对TCP来说无疑是有益的，因为TCP有充分的时间判断数据包到底是失序还是丢了来防止不必要的数据重传。当然严重的乱序则会让发送端以为是丢包一旦重复的ACK超过TCP的阈值，便会触发超时重传机制，以及时解决这种问题。

  2. 反向链路（ACK）乱序

    顾名思义，如果发生这种情况，就会导致发送端窗口快速前移，这会导致发送端出现不必要的流量突发，影响网络带宽。

答案解析

无

说一说你对IP分类的了解。

参考回答

                                  五类互联网地址

IP地址根据网络号和主机号来分，分为A、B、C三类及特殊地址D、E。 全0和全1的都保留不用。

  1. A类：(1.0.0.0-126.0.0.0)（默认子网掩码：255.0.0.0或 0xFF000000）第一个字节为网络号，后三个字节为主机号。该类IP地址的最前面为“0”，所以地址的网络号取值于1~126之间。一般用于大型网络。
  2. B类：(128.0.0.0-191.255.0.0)（默认子网掩码：255.255.0.0或0xFFFF0000）前两个字节为网络号，后两个字节为主机号。该类IP地址的最前面为“10”，所以地址的网络号取值于128~191之间。一般用于中等规模网络。
  3. C类：(192.0.0.0-223.255.255.0)（子网掩码：255.255.255.0或 0xFFFFFF00）前三个字节为网络号，最后一个字节为主机号。该类IP地址的最前面为“110”，所以地址的网络号取值于192~223之间。一般用于小型网络。
  4. D类：是多播地址。该类IP地址的最前面为“1110”，所以地址的网络号取值于224~239之间。一般用于多路广播用户 。
  5. E类：是保留地址。该类IP地址的最前面为“1111”，所以地址的网络号取值于240~255之间。

IP为什么要分类？

参考回答

根据IP地址访问终端是通过路由器，路由设备当中有一张路由表，该路由表记录了所有IP地址的位置，这样就可以进行包的转发了，如果我们不区分网络地址，那么这张路由表当中就要保存有所有IP地址的方向，这张路由表就会很大，就像下面说的那样：如果不分网络位和主机位，路由器的路由表就是都是32位的地址，那所有的路由器维护的路由表会很大，转发速度会变慢（因为查询变慢）。而且所有的路由器都要有全Internet的地址，所有人的路由器都要有足够的性能来存下全网地址。估计建造这样的Internet成本是现在的几万倍，甚至更高。

有了网络地址，就可以限定拥有相同网络地址的终端都在同一个范围内，那么路由表只需要维护这个网络地址的方向，就可以找到相应的终端了。

IPV4和IPV6有什么区别？

参考回答

IPv4和IPv6是是目前使用的两种Internet协议版本，IPv4和IPv6协议之间存在各种差异，包括它们的功能，但关键的一点是它生成的地址（地址空间）的数量的区别。

  1. 协议地址的区别

    （1）地址长度

    IPv4协议具有32位（4字节）地址长度；IPv6协议具有128位（16字节）地址长度。

    （2）地址的表示方法

    IPv4地址是以小数表示的二进制数。 IPv6地址是以十六进制表示的二进制数。

    （3）地址配置

    IPv4协议的地址可以通过手动或DHCP配置的。

    IPv6协议需要使用Internet控制消息协议版本6（ICMPv6）或DHCPv6的无状态地址自动配置（SLAAC）。

  2. 数据包的区别

    （1）包的大小

    IPv4协议的数据包需要576个字节，碎片可选 ；IPv6协议的数据包需要1280个字节，不会碎片。

    （2）包头

    IPv4协议的包头的长度为20个字节，不识别用于QoS处理的数据包流，包含checksum，包含最多40个字节的选项字段。

    IPv6协议的包头的长度为40个字节，包含指定QoS处理的数据包流的Flow Label字段，不包含checksum；IPv6协议没有字段，但IPv6扩展标头可用。

    （3）数据包碎片

    IPv4协议的数据包碎片会由转发路由器和发送主机完成。IPv6协议的数据包碎片仅由发送主机完成。

  3. DNS记录

    IPv4协议的地址（A）记录，映射主机名；指针（PTR）记录，IN-ADDR.ARPA DNS域。

    IPv6协议的地址（AAAA）记录，映射主机名；指针（PTR）记录，IP6.ARPA DNS域

  4. IPSec支持

    IPv4协议的IPSec支持只是可选的；IPv6协议有内置的IPSec支持。

  5. 地址解析协议

    IPv4协议：地址解析协议（ARP）可用于将IPv4地址映射到MAC地址。

    IPv6协议：地址解析协议（ARP）被邻居发现协议（NDP）的功能所取代。

  6. 身份验证和加密

    Pv6提供身份验证和加密；但IPv4不提供。

答案解析

无

说一下http和https的区别。

参考回答

https和https主要存在以下的区别：

  1. HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(以前的网易官网是http，而网易邮箱是 https 。)
  2. HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
  3. HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
  4. HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

答案解析

  1. 超文本传输协议（HTTP，HyperText Transfer Protocol）是互联网上应用最为广泛的一种网络协议。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。它可以使浏览器更加高效。HTTP 协议是以明文方式发送信息的，如果黑客截取了 Web 浏览器和服务器之间的传输报文，就可以直接获得其中的信息。

  2. HTTP原理

    （1）客户端的浏览器首先要通过网络与服务器建立连接，该连接是通过 TCP 来完成的，一般 TCP 连接的端口号是80。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和许可内容。

    （2）服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。

  3. HTTPS（Hyper Text Transfer Protocol over SecureSocket Layer）是以安全为目标的 HTTP 通道，是 HTTP 的安全版。HTTPS 的安全基础是 SSL。SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。SSL 协议可分为两层：SSL 记录协议（SSL Record Protocol），它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL 握手协议（SSL Handshake Protocol），它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

  4. HTTPS的工作原理

    我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

    客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图上图所示：

    （1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

    （2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

    （3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

    （4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

    （5）Web服务器利用自己的私钥解密出会话密钥。

    （6）Web服务器利用会话密钥加密与客户端之间的通信。

  5. HTTPS的优点

    尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

    （1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

    （2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

    （3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

    （4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

  6. HTTPS的缺点

    虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

    （1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

    （2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

    （3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

    （4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

    （5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

https为什么采用混合加密机制？

参考回答

一方面，第一阶段的非对称加密，保证了对称密钥的安全性；另一方面，第二阶段的对称加密，可以提高加密/解密处理的速度，提高数据传输的效率。

答案解析

  1. 为什么需要加密？

    因为http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了，他还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。最简单容易理解的就是对称加密。

  2. 什么是对称加密？

    就是有一个密钥，它可以对一段内容加密，加密后只能用它才能解密看到原本的内容，和我们日常生活中用的钥匙作用差不多。

  3. 用对称加密可行吗？

    如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那这个传输过程中密钥被别人劫持弄到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。 换种思路？试想一下，如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的，这样浏览器只要预存好世界上所有HTTPS网站的密钥就行啦！这么做显然不现实。 所以我们就需要神奇的非对称加密。

  4. 什么是非对称加密？

    有两把密钥，通常一把叫做公钥、一把叫做私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

  5. 用非对称加密可行吗？ 鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开这条数据。 然而由服务器到浏览器的这条路怎么保障安全？如果服务器用它的的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据时的安全性（其实仍有漏洞，下文会说）。

  6. 混合加密

    非对称加密耗时，非对称加密+对称加密结合可以吗？而且得尽量减少非对称加密的次数。当然是可以的，而且非对称加密、解密各只需用一次即可。以下就是加密过程：

    （1）某网站拥有用于非对称加密的公钥A、私钥A’。

    （2）浏览器像网站服务器请求，服务器把公钥A明文给传输浏览器。

    （3）浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。

    （4）服务器拿到后用私钥A’解密得到密钥X。

    （5）这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。

    完美！HTTPS基本就是采用了这种方案。

https支持什么加密算法？

参考回答

常见的对称加密算法有：DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES ；

常见的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）；

常见的Hash算法有：MD2、MD4、MD5、HAVAL、SHA；

答案解析

  1. 对称加密技术

    对称加密采用了对称密码编码技术，它的特点是文件加密和解密使用相同的密钥加密。也就是密钥也可以用作解密密钥，这种方法在密码学中叫做对称加密算法，对称加密算法使用起来简单快捷，密钥较短，且破译困难，除了数据加密标准（DES），另一个对称密钥加密系统是国际数据加密算法（IDEA），它比DES的加密性好，而且对计算机功能要求也没有那么高。对称加密算法在电子商务交易过程中存在几个问题：

（1）要求提供一条安全的渠道使通讯双方在首次通讯时协商一个共同的密钥。直接的面对面协商可能是不现实而且难于实施的，所以双方可能需要借助于邮件和电话等其它相对不够安全的手段来进行协商；

（2）密钥的数目难于管理。因为对于每一个合作者都需要使用不同的密钥，很难适应开放社会中大量的信息交流；

（3）对称加密算法一般不能提供信息完整性的鉴别。它无法验证发送者和接受者的身份；

（4）对称密钥的管理和分发工作是一件具有潜在危险的和烦琐的过程。对称加密是基于共同保守秘密来实现的，采用对称加密技术的贸易双方必须保证采用的是相同的密钥，保证彼此密钥的交换是安全可靠的，同时还要设定防止密钥泄密和更改密钥的程序。

假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1) 个密钥，密钥的生成和分发将成为企业信息部门的恶梦。

常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES

  1. 非对称加密技术

    与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。

    公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

    非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。

    非对称加密的典型应用是数字签名。

    常见的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

Hash算法（摘要算法）

  1. Hash算法

    Hash算法特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。

    常见的Hash算法有MD2、MD4、MD5、HAVAL、SHA

说一说HTTPS的秘钥交换过程。

参考回答

HTTPS的密钥交换过程如下：

  1. 客户端要访问一个网站，向支持https的服务器发起请求。

  2. 客户端向服务器发送自己支持的秘钥交换算法列表。

  3. 服务器选取一种秘钥交换算法加上CA证书返回给客户端。

  4. 客户端验证服务器是否合法，并生成一个随机数然后用协商好的加密算法加密生成随机秘钥，并用刚才从CA证书中拿到的公钥对其加密后发送给服务器。

  5. 服务器收到后用自己的私钥解密（中间人没有服务器的私钥，所以没有办法看到传输的数据，另外确认秘钥交换算法是在第一步，中间人是不知道秘钥交换算法（中间人是无法在第一步做手脚的，那等同于它自己就是一个真实客户端发起了一个新的请求，唯一一种情况攻击人有一个合法CA下发的证书，且客户端（一般为安卓设备）没有对CA下发的证书中的内容网站地址和当前请求地址做对比校验），就算攻击者有公钥，因为不知道协商协议，所以做不出来随机秘钥，顶多就是在传输过程中将报文拦截下来，乱改，但是给到服务器后，私钥是解不开乱改之后的密文的）。

  6. 服务器私钥解密之后，拿到对称秘钥，并且用它再加密一个信息，返回给浏览器。

    注意：最关键的一步就是在客户端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master，这个随机秘钥是用来计算最终的对称秘钥的，用公钥加密之后攻击人是不知道这个这个随机秘钥的，只有服务器才能解的开。

说一说HTTPS的证书认证过程。

参考回答

HTTPS的证书认证过程如下：

  1. 浏览器将自己支持的一套加密规则发送给网站。

  2. 网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

  3. 浏览器获得网站证书之后浏览器要做以下工作：

    （1） 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。 （2）如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。 （3）使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。

  4. 网站接收浏览器发来的数据之后要做以下的操作：

    （1） 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。 （2） 使用密码加密一段握手消息，发送给浏览器。

  5. 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

HTTP请求头中包含什么内容？

参考回答

HTTP请求头中包含如下三个内容：

 **User-Agent**：产生请求的浏览器类型。

Accept：客户端可识别的内容类型列表。

Host：主机地址。

答案解析

  1. 请求报文(请求行/请求头/请求数据/空行)

    （1） 请求行

    求方法字段、URL字段和HTTP协议版本

    例如：GET /index.html HTTP/1.1

    get方法将数据拼接在url后面，传递参数受限

    请求方法：

    GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT

    （2） 请求头(key value形式)

    User-Agent：产生请求的浏览器类型。

    Accept：客户端可识别的内容类型列表。

    Host：主机地址

    （3） 请求数据

    post方法中，会把数据以key value形式发送请求

    （4） 空行

    发送回车符和换行符，通知服务器以下不再有请求头

  2. 响应报文(状态行、消息报头、响应正文)

    状态行

消息报头

响应正文

HTTP是基于TCP还是UDP？

参考回答

HTTP是基于TCP的。

HTTP协议是建立在请求/响应模型上的。首先由客户建立一条与服务器的TCP链接，并发送一个请求到服务器，请求中包含请求方法、URI、协议版本以及 相关的MIME样式的消息。服务器响应一个状态行，包含消息的协议版本、一个成功和失败码以及相关的MIME式样的消息。 HTTP/1.0为每一次HTTP的请求/响应建立一条新的TCP链接，因此一个包含HTML内容和图片的页面将需要建立多次的短期的TCP链接。一次TCP链接的建立将需要3次握手。 另 外，为了获得适当的传输速度，则需要TCP花费额外的回路链接时间（RTT）。每一次链接的建立需要这种经常性的开销，而其并不带有实际有用的数据，只是 保证链接的可靠性，因此HTTP/1.1提出了可持续链接的实现方法。HTTP/1.1将只建立一次TCP的链接而重复地使用它传输一系列的请求/响应消 息，因此减少了链接建立的次数和经常性的链接开销。

答案解析

无

HTTP1.1和HTTP2.0有什么区别？

参考回答

  1. HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

  2. 在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。 HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

  3. 服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。

    为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。

答案解析

无

HTTP2.0和HTTP3.0有什么区别？

参考回答

HTTP2.0和HTTP3.0的区别在于前者使用tcp协议而后者使用udp协议。

答案解析

http发展历程：从http0.9 到 http3.0

  1. HTTP0.9

    最简单的只有请求行 GET index.html

  2. HTTP1.0

    （1）增加请求头、响应头，让请求和相应都更清晰

    （2）增加状态码，让响应更清晰

    （3）增加缓存功能，已请求过的内容再次请求时就可直接使用缓存

GET index.html HTTP/1.0  accept: application/html accept-charset: utf-8  accept-encoding: gzip  accept-language: zh-CN
HTTP/1.0 200 OK  <!DOCTYPE html>  <html>  <head></head>  <body>hello world!</body>  </html>
a. accept 解决文件格式问题，是json还是html，浏览器根据不同文件格式来解析文件；

b. accept-charset 解决文件编码问题，告知浏览器如何将字符流解析成字节流；

c. accept-encoding 解决大文件压缩问题，浏览器采用指定的解压方式来解压；

d. accept-language 解决国际化问题，不同国家请求不同语言的文件。

  1. HTTP1.1

    （1）持久连接，多个http请求使用同一个tcp连接，减少了tcp建立连接时的开销

    （2）客户端和服务器之间可以建立多个tcp连接以解决队头阻塞的问题

    （3）响应体可以分块传输，无需一次传输全部内容

    （4）响应头增加content-length字段满足动态内容无法一次计算出长度和无法一次传输完成的问题

    （5）增加了安全机制和cookie机制

  2. HTTP2.0 多路复用，客户端和服务器之间只建立一条tcp，每个http请求被切分成多帧，多个http的帧混合在一起在一个tcp连接上传送

  3. HTTP3.0 不再使用tcp协议，因为tcp依然是顺序发送，顺序接收的，依然有队头堵塞问题，干掉tcp才能解决队头堵塞问题。google的QUIC就使用了udp协议。

谈谈HTTP的缓存机制，服务器如何判断当前缓存过期？

参考答案：

  • http 缓存策略

    浏览器每次发起请求时，先在本地缓存中查找结果以及缓存标识，根据缓存标识来判断是否使用本地缓存。如果缓存有效，则使用本地缓存；否则，则向服务器发起请求并携带缓存标识。根据是否需向服务器发起HTTP请求，将缓存过程划分为两个部分： 强制缓存和协商缓存，强缓优先于协商缓存。

    • 强缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
    • 协商缓存，让客户端与服务器之间能实现缓存文件是否更新的验证、提升缓存的复用率，将缓存信息中的Etag和Last-Modified 通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存。

    HTTP缓存都是从第二次请求开始的：

    • 第一次请求资源时，服务器返回资源，并在response header中回传资源的缓存策略；

    • 第二次请求时，浏览器判断这些请求参数，击中强缓存就直接200，否则就把请求参数加到request header头中传给服务器，看是否击中协商缓存，击中则返回304，否则服务器会返回新的资源。这是缓存运作的一个整体流程图：

  • 强缓存

    • 强缓存命中则直接读取浏览器本地的资源，在network中显示的是from memory或者from disk
    • 控制强制缓存的字段有：Cache-Control（http1.1）和Expires（http1.0）
    • Cache-control是一个相对时间，用以表达自上次请求正确的资源之后的多少秒的时间段内缓存有效。
    • Expires是一个绝对时间。用以表达在这个时间点之前发起请求可以直接从浏览器中读取数据，而无需发起请求
    • Cache-Control的优先级比Expires的优先级高。前者的出现是为了解决Expires在浏览器时间被手动更改导致缓存判断错误的问题。 如果同时存在则使用Cache-control。

  • 强缓存-expires

    • 该字段是服务器响应消息头字段，告诉浏览器在过期时间之前可以直接从浏览器缓存中存取数据。
    • Expires 是 HTTP 1.0 的字段，表示缓存到期时间，是一个绝对的时间 (当前时间+缓存时间)。在响应消息头中，设置这个字段之后，就可以告诉浏览器，在未过期之前不需要再次请求。
    • 由于是绝对时间，用户可能会将客户端本地的时间进行修改，而导致浏览器判断缓存失效，重新请求该资源。此外，即使不考虑修改，时差或者误差等因素也可能造成客户端与服务端的时间不一致，致使缓存失效。
    • 优势特点
      • HTTP 1.0 产物，可以在HTTP 1.0和1.1中使用，简单易用。
      • 以时刻标识失效时间。
    • 劣势问题
      • 时间是由服务器发送的(UTC)，如果服务器时间和客户端时间存在不一致，可能会出现问题。
      • 存在版本问题，到期之前的修改客户端是不可知的。

  • 强缓存-cache-control

    • 已知Expires的缺点之后，在HTTP/1.1中，增加了一个字段Cache-control，该字段表示资源缓存的最大有效时间，在该时间内，客户端不需要向服务器发送请求。
    • 这两者的区别就是前者是绝对时间，而后者是相对时间。下面列举一些 Cache-control 字段常用的值：(完整的列表可以查看MDN)
      • max-age：即最大有效时间。
      • must-revalidate：如果超过了 max-age 的时间，浏览器必须向服务器发送请求，验证资源是否还有效。
      • no-cache：不使用强缓存，需要与服务器验证缓存是否新鲜。
      • no-store: 真正意义上的“不要缓存”。所有内容都不走缓存，包括强制和对比。
      • public：所有的内容都可以被缓存 (包括客户端和代理服务器， 如 CDN)
      • private：所有的内容只有客户端才可以缓存，代理服务器不能缓存。默认值。
    • Cache-control 的优先级高于 Expires，为了兼容 HTTP/1.0 和 HTTP/1.1，实际项目中两个字段都可以设置。
    • 该字段可以在请求头或者响应头设置，可组合使用多种指令：
      • 可缓存性
        • public：浏览器和缓存服务器都可以缓存页面信息
        • private：default，代理服务器不可缓存，只能被单个用户缓存
        • no-cache：浏览器器和服务器都不应该缓存页面信息，但仍可缓存，只是在缓存前需要向服务器确认资源是否被更改。可配合private， 过期时间设置为过去时间。
        • only-if-cache：客户端只接受已缓存的响应
      • 到期
        • max-age=：缓存存储的最大周期，超过这个周期被认为过期。
        • s-maxage=：设置共享缓存，比如can。会覆盖max-age和expires。
        • max-stale[=]：客户端愿意接收一个已经过期的资源
        • min-fresh=：客户端希望在指定的时间内获取最新的响应
        • stale-while-revalidate=：客户端愿意接收陈旧的响应，并且在后台一部检查新的响应。时间代表客户端愿意接收陈旧响应 的时间长度。
        • stale-if-error=：如新的检测失败，客户端则愿意接收陈旧的响应，时间代表等待时间。
      • 重新验证和重新加载
        • must-revalidate：如页面过期，则去服务器进行获取。
        • proxy-revalidate：用于共享缓存。
        • immutable：响应正文不随时间改变。
      • 其他
        • no-store：绝对禁止缓存
        • no-transform：不得对资源进行转换和转变。例如，不得对图像格式进行转换。
    • 优势特点
      • HTTP 1.1 产物，以时间间隔标识失效时间，解决了Expires服务器和客户端相对时间的问题。
      • 比Expires多了很多选项设置。
    • 劣势问题
      • 存在版本问题，到期之前的修改客户端是不可知的。

  • 协商缓存

    • 协商缓存的状态码由服务器决策返回200或者304
    • 当浏览器的强缓存失效的时候或者请求头中设置了不走强缓存，并且在请求头中设置了If-Modified-Since 或者 If-None-Match 的时候，会将这两个属性值到服务端去验证是否命中协商缓存，如果命中了协商缓存，会返回 304 状态，加载浏览器缓存，并且响应头会设置 Last-Modified 或者 ETag 属性。
    • 对比缓存在请求数上和没有缓存是一致的，但如果是 304 的话，返回的仅仅是一个状态码而已，并没有实际的文件内容，因此 在响应体体积上的节省是它的优化点。
    • 协商缓存有 2 组字段(不是两个)，控制协商缓存的字段有：Last-Modified/If-Modified-since（http1.0）和Etag/If-None-match（http1.1）
    • Last-Modified/If-Modified-since表示的是服务器的资源最后一次修改的时间；Etag/If-None-match表示的是服务器资源的唯一标 识，只要资源变化，Etag就会重新生成。
    • Etag/If-None-match的优先级比Last-Modified/If-Modified-since高。

  • 协商缓存-协商缓存-Last-Modified/If-Modified-since

    • 服务器通过 Last-Modified 字段告知客户端，资源最后一次被修改的时间，例如 Last-Modified: Mon, 10 Nov 2018 09:10:11 GMT
    • 浏览器将这个值和内容一起记录在缓存数据库中。
    • 下一次请求相同资源时时，浏览器从自己的缓存中找出“不确定是否过期的”缓存。因此在请求头中将上次的 Last-Modified 的值写入到请求头的 If-Modified-Since 字段
    • 服务器会将 If-Modified-Since 的值与 Last-Modified 字段进行对比。如果相等，则表示未修改，响应 304；反之，则表示修改了，响应 200 状态码，并返回数据。
    • 优势特点
      • 不存在版本问题，每次请求都会去服务器进行校验。服务器对比最后修改时间如果相同则返回304，不同返回200以及资源内容。
    • 劣势问题
      • 只要资源修改，无论内容是否发生实质性的变化，都会将该资源返回客户端。例如周期性重写，这种情况下该资源包含的数据实际上一样的。
      • 以时刻作为标识，无法识别一秒内进行多次修改的情况。 如果资源更新的速度是秒以下单位，那么该缓存是不能被使用的，因为它的时间单位最低是秒。
      • 某些服务器不能精确的得到文件的最后修改时间。
      • 如果文件是通过服务器动态生成的，那么该方法的更新时间永远是生成的时间，尽管文件可能没有变化，所以起不到缓存的作用。

  • 协商缓存-Etag/If-None-match

    • 为了解决上述问题，出现了一组新的字段 Etag 和 If-None-Match
    • Etag 存储的是文件的特殊标识(一般都是 hash 生成的)，服务器存储着文件的 Etag 字段。之后的流程和 Last-Modified 一致，只是 Last-Modified 字段和它所表示的更新时间改变成了 Etag字段和它所表示的文件 hash，把 If-Modified-Since 变成了 If-None-Match。服务器同样进行比较，命中返回 304, 不命中返回新资源和 200。
    • 浏览器在发起请求时，服务器返回在Response header中返回请求资源的唯一标识。在下一次请求时，会将上一次返回的Etag值赋值给If-No-Matched并添加在Request Header中。服务器将浏览器传来的if-no-matched跟自己的本地的资源的ETag做对比，如果匹配，则返回304通知浏览器读取本地缓存，否则返回200和更新后的资源。
    • Etag 的优先级高于 Last-Modified。
    • 优势特点
      • 可以更加精确的判断资源是否被修改，可以识别一秒内多次修改的情况。
      • 不存在版本问题，每次请求都回去服务器进行校验。
    • 劣势问题
      • 计算ETag值需要性能损耗。
      • 分布式服务器存储的情况下，计算ETag的算法如果不一样，会导致浏览器从一台服务器上获得页面内容后到另外一台服务器上进行验证时现ETag不匹配的情况。

介绍一下HTTP协议中的长连接和短连接。

参考回答

HTTP协议的底层使用TCP协议，所以HTTP协议的长连接和短连接在本质上是TCP层的长连接和短连接。由于TCP建立连接、维护连接、释放连接都是要消耗一定的资源，浪费一定的时间。所对于服务器来说，频繁的请求释放连接会浪费大量的时间，长时间维护太多的连接的话又需要消耗资源。所以长连接和短连接并不存在优劣之分，只是适用的场合不同而已。长连接和短连接分别有如下优点和缺点：

长连接优点：可以节省较多的TCP连接和释放的操作，节约时间，对于频繁请求资源的用户来说，适合长连接。

长连接缺点：由于有保活功能，当遇到大量的恶意连接时，服务器的压力会越来越大。这时服务器需要采取一些策略，关闭一些长时间没有进行读写事件的的连接。

短连接优点：短连接对服务器来说管理比较简单，只要存在的连接都是有效连接，不需要额外的控制手段，而且不会长时间占用资源 。

短连接缺点：如果客户端请求频繁的话，会在TCP的建立和释放上浪费大量的时间。

注意：从HTTP/1.1版本起，默认使用长连接用以保持连接特性。使用长连接的HTTP协议，会在响应消息报文段加入: Connection: keep-alive。TCP中也有keep alive，但是TCP中的keep alive只是探测TCP连接是否活着，而HTTP中的keep-alive是让一个TCP连接获得更久一点。

答案解析

无

介绍一下HTTPS的流程。

参考回答

HTTPS在传输的过程中会涉及到三个密钥：服务器端的公钥和私钥，用来进行非对称加密；客户端生成的随机密钥，用来进行对称加密。一个HTTPS请求实际上包含了两次HTTP传输，如下图可以细分为以下8步：

  1. 客户端向服务器发起HTTPS请求，连接到服务器的443端口
  2. 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
  3. 服务器将自己的公钥发送给客户端。
  4. 客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
  5. 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
  6. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
  7. 然后服务器将加密后的密文发送给客户端。
  8. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

答案解析

无

介绍一下HTTP的失败码。

参考回答

HTTP的错误码包含客户端错误4XX 和服务端错误5XX ，两种错误分别如下：

  1. 客户端错误 4XX

    这类的状态码是适用于客户端似乎有错误的情况。除了响应给HEAD请求外，服务器应该包含一个包括错误情况描述的实体，和它是暂时的还是永久性的。这些状态码适用于任何请求方法。用户代理应该展示所有包含的实体给用户。

    如果客户端正在发送数据，使用TCP的服务器应该在服务器关闭输出链接时，仔细确保客户端确认收到包含响应的数据包（receipt of the packet(s) ） 。如果客户端继续在服务器关闭后发送数据，服务器的TCP栈将会发生一个重置包给客户端，这可能会在 HTTP 应用程序读取和解释客户端的未确认输入缓冲区（input buffers）之前将其擦除。

    400(错误请求) 服务器不理解请求的语法。

    401(未授权) 请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。

    403(已禁止) 服务器拒绝请求。如果在 Googlebot 尝试抓取您网站上的有效网页时显示此状态代码(您可在 Google 网站管理员工具中诊断下的网络抓取页面上看到此状态代码)，那么，这可能是您的服务器或主机拒绝 Googlebot 对其进行访问。

    404(未找到) 服务器找不到请求的网页。例如，如果请求是针对服务器上不存在的网页进行的，那么，服务器通常会返回此代码。

    如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具”诊断”标签的 robots.txt 页上发现此状态，那么，这是正确的状态。然而，如果您有 robots.txt 文件而又发现了此状态，那么，这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。(该文件应当位于顶级域名上，且应当名为 robots.txt)。

    如果您在 Googlebot 尝试抓取的网址上发现此状态(位于”诊断”标签的 HTTP 错误页上)，那么，这表示 Googlebot 所追踪的可能是另一网页中的无效链接(旧链接或输入有误的链接)。

    405(方法禁用) 禁用请求中所指定的方法。

    406(不接受) 无法使用请求的内容特性来响应请求的网页。

    407(需要代理授权) 此状态代码与 401(未授权)类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。

    408(请求超时) 服务器等候请求时超时。

    409(冲突) 服务器在完成请求时发生冲突。服务器必须包含有关响应中所发生的冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。

    410(已删除) 如果请求的资源已被永久删除，那么，服务器会返回此响应。该代码与 404(未找到)代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已被永久删除，那么，您应当使用 301 代码指定该资源的新位置。

    411(需要有效长度) 服务器不会接受包含无效内容长度标头字段的请求。

    412(未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。

    413(请求实体过大) 服务器无法处理请求，因为请求实体过大，已超出服务器的处理能力。

    414(请求的 URI 过长) 请求的 URI(通常为网址)过长，服务器无法进行处理。

    415(不支持的媒体类型) 请求的格式不受请求页面的支持。

    416(请求范围不符合要求) 如果请求是针对网页的无效范围进行的，那么，服务器会返回此状态代码。

    417(未满足期望值) 服务器未满足”期望”请求标头字段的要求。

  2. 服务端错误 5XX

    响应状态码已数字5开头，表明了这类服务器知道其错误或者无法执行请求的情况。出了响应HEAD请求外，服务器应该包括一个包含错误情况说明的实体，以及他是暂时地还是永久性的，用户代理应该将所有包含的实体展示给用户。这些响应代码适用于任何请求方法。

    500(服务器内部错误) 服务器遇到错误，无法完成请求。

    501(尚未实施) 服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。

    502(错误网关) 服务器作为网关或代理，从上游服务器收到了无效的响应。

    503(服务不可用) 目前无法使用服务器(由于超载或进行停机维护)。通常，这只是一种暂时的状态。

    504(网关超时) 服务器作为网关或代理，未及时从上游服务器接收请求。

    505(HTTP 版本不受支持) 服务器不支持请求中所使用的 HTTP 协议版本。

说一说你知道的http状态码。

参考回答

HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型，分类及分类描述如下表：

分类 分类描述
1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误

各类别常见状态码有如下几种：

  1. 2xx （3种）

    200 OK：表示从客户端发送给服务器的请求被正常处理并返回；

    204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；

    206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。

  2. 3xx （5种）

    301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；

    302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；

    301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）

    303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；

    302与303的区别：后者明确表示客户端应当采用GET方式获取资源

    304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回该状态码；

    307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；

  3. 4xx （4种）

    400 Bad Request：表示请求报文中存在语法错误；

    401 Unauthorized：未经许可，需要通过HTTP认证；

    403 Forbidden：服务器拒绝该次访问（访问权限出现问题）

    404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；

  4. 5xx （2种）

    500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；

    503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

答案解析

无

301和302有什么区别？

参考回答

301和302的区别在于，301重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址。302重定向是暂时的重定向，搜索引擎会抓取新的内容而保存旧的网址。由于效劳器前往302代码，搜索引擎以为新的网址只是暂时的。

302和304有什么区别？

参考回答

302和304是网页请求的两个不同的响应状态码。302 （临时移动）表示 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。 304 （未修改）表示 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。

答案解析

无

请描述一次完整的HTTP请求的过程。

参考回答

                                         DNS解析流程图
  1. 首先客户端位置是一台电脑或手机，在打开浏览器以后，比如输入http://www.zdns.cn的域名，它首先是由浏览器发起一个DNS解析请求，如果本地缓存服务器中找不到结果，则首先会向根服务器查询，根服务器里面记录的都是各个顶级域所在的服务器的位置，当向根服务器请求http://www.zdns.cn的时候，根服务器就会返回.cn服务器的位置信息；
  2. 递归服务器拿到.cn的权威服务器地址以后，就会寻问.cn的权威服务器，知不知道http://www.zdns.cn的位置。这个时候.cn权威服务器查找并返回http://zdns.cn服务器的地址；
  3. 继续向http://zdns.cn的权威服务器去查询这个地址，由http://zdns.cn的服务器给出了地址：202.173.11.10；
  4. 最终进入http的链接，顺利访问网站；

补充说明：一旦递归服务器拿到解析记录以后，就会在本地进行缓存，如果下次客户端再请求本地的递归域名服务器相同域名的时候，就不会再这样一层一层查了，因为本地服务器里面已经有缓存了，这个时候就直接把http://www.zdns.cn的记录返回给客户端就可以了。

什么是重定向？

参考回答

**重定向(Redirect)**就是通过各种方法将各种网络请求重新定个方向转到其它位置（如：网页重定向、域名的重定向、路由选择的变化也是对数据报文经由路径的一种重定向）。

答案解析

  1. 需要重定向的情况

    （1）网站调整（如改变网页目录结构）；

    （2）网页被移到一个新地址；

    （3）网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

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

  2. 常用的重定向的方式

    （1）301 redirect—–永久性转移

    当用户或搜索引擎向网站服务器发出浏览请求时，服务器返回的HTTP数据流中头信息(header)中的状态码的一种，表示本网页永久性转移到另一个地址。

    （2）302 redirect—–暂时性转移 (Temporarily Moved )

    也被认为是暂时重定向（temporary redirect），一条对网站浏览器的指令来显示浏览器被要求显示的不同的URL，当一个网页经历过短期的URL的变化时使用。一个暂时重定向是一种服务器端的重定向，能够被搜索引擎蜘蛛正确地处理。

  3. 新旧重定向方式的区别

    302重定向是暂时的重定向，搜索引擎会抓取新的内容而保存旧的网址。由于效劳器前往302代码，搜索引擎以为新的网址只是暂时的；

    301重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址。

  4. 为什么302 重定向和网址劫持有关联

    从网址A 做一个302 重定向到网址B 时，主机服务器的隐含意思是网址A 随时有可能改主意，重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下，当收到302 重定向时，一般只要去抓取目标网址就可以了，也就是说网址B。如果搜索引擎在遇到302 转向时，百分之百的都抓取目标网址B 的话，就不用担心网址URL 劫持了。问题就在于，有的时候搜索引擎，尤其是Google，并不能总是抓取目标网址。

    比如说，有的时候A 网址很短，但是它做了一个302 重定向到B 网址，而B 网址是一个很长的乱七八糟的URL 网址，甚至还有可能包含一些问号之类的参数。很自然的，A 网址更加用户友好，而B 网址既难看，又不用户友好。这时Google 很有可能会仍然显示网址A。由于搜索引擎排名算法只是程序而不是人，在遇到302 重定向的时候，并不能像人一样的去准确判定哪一个网址更适当，这就造成了网址URL 劫持的可能性。也就是说，一个不道德的人在他自己的网址A 做一个302 重定向到你的网址B，出于某种原因， Google 搜索结果所显示的仍然是网址A，但是所用的网页内容却是你的网址B 上的内容，这种情况就叫做网址URL 劫持。你辛辛苦苦所写的内容就这样被别人偷走了。

    302 重定向所造成的网址URL 劫持现象，已经存在一段时间了。不过到目前为止，似乎也没有什么更好的解决方法。在正在进行的数据中心转换中，302 重定向问题也是要被解决的目标之一。从一些搜索结果来看，网址劫持现象有所改善，但是并没有完全解决。

重定向和请求转发有什么区别？

参考回答

  1. 请求转发

    客户首先发送一个请求到服务器端，服务器端发现匹配的servlet，并指定它去执行，当这个servlet执行完之后，它要调用getRequestDispacther()方法，把请求转发给指定的student_list.jsp,整个流程都是在服务器端完成的，而且是在同一个请求里面完成的，因此servlet和jsp共享的是同一个request，在servlet里面放的所有东西，在student_list中都能取出来，因此，student_list能把结果getAttribute()出来，getAttribute()出来后执行完把结果返回给客户端。整个过程是一个请求，一个响应。

  2. 重定向

    客户发送一个请求到服务器，服务器匹配servlet，servlet处理完之后调用了sendRedirect()方法，立即向客户端返回这个响应，响应行告诉客户端你必须要再发送一个请求，去访问student_list.jsp，紧接着客户端收到这个请求后，立刻发出一个新的请求，去请求student_list.jsp,这里两个请求互不干扰，相互独立，在前面request里面setAttribute()的任何东西，在后面的request里面都获得不了。可见，在sendRedirect()里面是两个请求，两个响应。（服务器向浏览器发送一个302状态码以及一个location消息头，浏览器收到请求后会向再次根据重定向地址发出请求）

  3. 二者区别

    （1）请求次数：重定向是浏览器向服务器发送一个请求并收到响应后再次向一个新地址发出请求，转发是服务器收到请求后为了完成响应跳转到一个新的地址；重定向至少请求两次，转发请求一次；

    （2）地址栏不同：重定向地址栏会发生变化，转发地址栏不会发生变化；

    （3）是否共享数据：重定向两次请求不共享数据，转发一次请求共享数据（在request级别使用信息共享，使用重定向必然出错）；

    （4）跳转限制：重定向可以跳转到任意URL，转发只能跳转本站点资源；

    （5）发生行为不同：重定向是客户端行为，转发是服务器端行为。

答案解析

无

介绍一下DNS寻址的过程。

参考回答

                                         DNS解析流程图
  1. 首先客户端位置是一台电脑或手机，在打开浏览器以后，比如输入http://www.zdns.cn的域名，它首先是由浏览器发起一个DNS解析请求，如果本地缓存服务器中找不到结果，则首先会向根服务器查询，根服务器里面记录的都是各个顶级域所在的服务器的位置，当向根服务器请求http://www.zdns.cn的时候，根服务器就会返回.cn服务器的位置信息；
  2. 递归服务器拿到.cn的权威服务器地址以后，就会寻问.cn的权威服务器，知不知道http://www.zdns.cn的位置。这个时候.cn权威服务器查找并返回http://zdns.cn服务器的地址；
  3. 继续向http://zdns.cn的权威服务器去查询这个地址，由http://zdns.cn的服务器给出了地址：202.173.11.10；
  4. 最终进入http的链接，顺利访问网站；

补充说明：一旦递归服务器拿到解析记录以后，就会在本地进行缓存，如果下次客户端再请求本地的递归域名服务器相同域名的时候，就不会再这样一层一层查了，因为本地服务器里面已经有缓存了，这个时候就直接把http://www.zdns.cn的记录返回给客户端就可以了。

答案解析

  1. 什么是DNS

    DNS就是域名系统，是因特网中的一项核心服务，是用于实现域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。

  2. 域名解析结构

    如上图所示，域名结构是树状结构，树的最顶端代表根服务器，根的下一层就是由我们所熟知的.com、.net、.cn等通用域和.cn、.uk等国家域组成，称为顶级域。网上注册的域名基本都是二级域名，比如http://baidu.com、http://taobao.com等等二级域名，它们基本上是归企业和运维人员管理。接下来是三级或者四级域名，这里不多赘述。总体概括来说域名是由整体到局部的机制结构。

说一说你对TIME_WAIT的理解。

参考回答

  1. 出现 TIME_WAIT的状态原因

    TIME_WAIT状态之所以存在,是为了保证网络的可靠性。由于TCP连接是双向的，所以在关闭连接的时候，两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭，后发送FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留2MSL时长。如果Server端一直没有向client端发送FIN消息(调用close() API)，那么这个CLOSE_WAIT会一直存在下去。

  2. MSL概念

    其指的是报文段的最大生存时间。如果报文段在网络中活动了MSL时间，还没有被接收，那么就会被丢弃。关于MSL的大小，RFC 793协议中给出的建议是2分钟，不过Linux中，通常是半分钟。

  3. TIME_WAIT持续两个MSL的作用

    首先，可靠安全地关闭TCP连接。比如网络拥塞，如果主动关闭方最后一个ACK没有被被动关闭方接收到，这时被动关闭方会对FIN进行超时重传，在这时尚未关闭的TIME_WAIT就会把这些尾巴问题处理掉，不至于对新连接及其他服务产生影响。其次，防止由于没有持续TIME_WAIT时间导致的新的TCP连接建立起来，延迟的FIN重传包会干扰新的连接。

  4. TIME_WAIT占用的资源

    少量内存（大概4K）和一个文件描述符fd。

  5. TIME_WAIT关闭的危害

    首先，当网络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包到达后会直接影响新的TCP连接；其次，当网络情况不好时，同时没有TIME_WAIT等待时，关闭连接后无新连接，那么当接收到被动方重传或延迟的FIN包后，会给被动方回送一个RST包，可能会影响被动方其他的服务连接。

答案解析

当client端传输完成数据，或者需要断开连接时：

  1. Client端发送一个FIN报文给Server端。表示要终止Client到Server这个方向的连接。通过调用close(socket) API。表示Client不再会发送数据到Server端。(但Server还能继续发给Client端)。Client状态变为FIN_WAIT_1。
  2. Server端收到FIN后，发送一个ACK报文给Client端(序号为M+1)。Server状态变为CLOSE_WAIT，Client收到序号为(M+1)的ACK后状态变为FIN_WAIT_2。Server端也发送一个FIN报文给Client端。(序号为N) 表示Server也要终止到Client端这个方向的连接。通过调用close(socket) API。Server端状态变为LAST_ACK。
  3. Client端收到报文FIN后，也发送一个ACK报文给服务器。(序号N+1)，Client状态变为TIME_WAIT。
  4. Server端收到序号为(N+1)的ACK， Server的状态变为CLOSED。
  5. 等带2MSL之后，Client的状态也变为CLOSE。

至此，一个完整的TCP连接就关闭了。

TIME_WAIT、CLOSE_WAIT状态发生在哪一步？

参考回答

  1. TIME_WAIT状态发生在客户端主动关闭连接时，发送最后一个ack后；CLOSE_WAIT状态发生在在Sever端收到Client的FIN消息之后。

  2. 出现 TIME_WAIT的状态原因

    TIME_WAIT状态之所以存在,是为了保证网络的可靠性。由于TCP连接是双向的，所以在关闭连接的时候，两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭，后发送FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留2MSL时长。如果Server端一直没有向client端发送FIN消息(调用close() API)，那么这个CLOSE_WAIT会一直存在下去。

  3. 出现CLOSE_WAIT的状态原因

    假设最终的ACK丢失，server将重发FIN，client必须维护TCP状态信息以便可以重发最终的ACK，否则会发送RST，结果server认为发生错误。TCP实现必须可靠地终止连接的两个方向(全双工关闭)，client必须进入 TIME_WAIT 状态，因为client可能面临重发最终ACK的情形。

  4. 为什么 TIME_WAIT 状态需要保持 2MSL 这么长的时间？

    如果 TIME_WAIT 状态保持时间不足够长(比如小于2MSL)，第一个连接就正常终止了。第二个拥有相同相关五元组的连接出现，而第一个连接的重复报文到达，干扰了第二个连接。TCP实现必须防止某个连接的重复报文在连接终止后出现，所以让TIME_WAIT状态保持时间足够长(2MSL)，连接相应方向上的TCP报文要么完全响应完毕，要么被丢弃。建立第二个连接的时候，不会混淆。

答案解析

当client端传输完成数据，或者需要断开连接时：

  1. Client端发送一个FIN报文给Server端。表示要终止Client到Server这个方向的连接。通过调用close(socket) API。表示Client不再会发送数据到Server端。(但Server还能继续发给Client端)。Client状态变为FIN_WAIT_1。
  2. Server端收到FIN后，发送一个ACK报文给Client端(序号为M+1)。Server状态变为CLOSE_WAIT，Client收到序号为(M+1)的ACK后状态变为FIN_WAIT_2。Server端也发送一个FIN报文给Client端。(序号为N) 表示Server也要终止到Client端这个方向的连接。通过调用close(socket) API。Server端状态变为LAST_ACK。
  3. Client端收到报文FIN后，也发送一个ACK报文给服务器。(序号N+1)，Client状态变为TIME_WAIT。
  4. Server端收到序号为(N+1)的ACK， Server的状态变为CLOSED。
  5. 等带2MSL之后，Client的状态也变为CLOSE。

至此，一个完整的TCP连接就关闭了。

有大量的TIME_WAIT状态怎么办？

参考回答

  1. time_wait 状态的影响

    TCP 连接中，主动发起关闭连接的一端，会进入 time_wait 状态，time_wait 状态，默认会持续 2 MSL（报文的最大生存时间），一般是 2x2 mins，time_wait 状态下，TCP 连接占用的端口，无法被再次使用，TCP 端口数量，上限是 6.5w（65535，16 bit），大量 time_wait 状态存在，会导致新建 TCP 连接会出错，address already in use : connect异常。

  2. 解决办法

    （1）客户端：HTTP 请求的头部，connection 设置为 keep-alive，保持存活一段时间：现在的浏览器，一般都这么进行了 。

    （2）服务器端

    a. 允许 time_wait状态的 socket 被重用

    b. 缩减 time_wait 时间，设置为 1 MSL（即，2 mins）

答案解析

无

请介绍socket通信的具体步骤。

参考回答

sockets（套接字）编程有三种：流式套接字（SOCK_STREAM），数据报套接字（SOCK_DGRAM），原始套接字（SOCK_RAW）；基于TCP的socket编程是采用的流式套接字。

  1. 服务器端编程的步骤

    （1）加载套接字库，创建套接字(WSAStartup()/socket())；

    （2）绑定套接字到一个IP地址和一个端口上(bind())；

    （3）将套接字设置为监听模式等待连接请求(listen())；

    （4）请求到来后，接受连接请求，返回一个新的对应于此次连接的套接字(accept())；

    （5）用返回的套接字和客户端进行通信(send()/recv())；

    （6）返回，等待另一连接请求；

    （7）关闭套接字，关闭加载的套接字库(closesocket()/WSACleanup())。

  2. 客户端编程的步骤：

    （1）加载套接字库，创建套接字(WSAStartup()/socket())；

    （2）向服务器发出连接请求(connect())；

    （3）和服务器端进行通信(send()/recv())；

    （4）关闭套接字，关闭加载的套接字库(closesocket()/WSACleanup())。

答案解析

//代码实例（服务器） 
#include <stdio.h> 
#include <Winsock2.h> 
void main() { 
  WORD wVersionRequested; 
  WSADATA wsaData;  
  int err;   
  wVersionRequested = MAKEWORD( 1, 1 );   
  err = WSAStartup( wVersionRequested, &wsaData ); 
  if ( err != 0 ) {  
    return; 
  }
  if ( LOBYTE( wsaData.wVersion ) != 1 ||   
      HIBYTE( wsaData.wVersion ) != 1 ) {   
    WSACleanup( ); 
    return;
  }
  SOCKET sockSrv=socket(AF_INET,SOCK_STREAM,0); 
  SOCKADDR_IN addrSrv; 
  addrSrv.sin_addr.S_un.S_addr=htonl(INADDR_ANY); 
  addrSrv.sin_family=AF_INET;
  addrSrv.sin_port=htons(6000);  
  bind(sockSrv,(SOCKADDR*)&addrSrv,sizeof(SOCKADDR));  
  listen(sockSrv,5);    
  SOCKADDR_IN addrClient; 
  int len=sizeof(SOCKADDR);  
  while(1)  {  
    SOCKET sockConn=accept(sockSrv,(SOCKADDR*)&addrClient,&len); 
    char sendBuf[50]; 
    sprintf(sendBuf,"Welcome %s to here!",inet_ntoa(addrClient.sin_addr));   
    send(sockConn,sendBuf,strlen(sendBuf)+1,0); 
    char recvBuf[50];   
    recv(sockConn,recvBuf,50,0);  
    printf("%s\n",recvBuf); 
    closesocket(sockConn);  
  }
}

//代码实例（客户端）
#include <stdio.h> 
#include <Winsock2.h> 
void main() { 
  WORD wVersionRequested; 
  WSADATA wsaData;  
  int err;  
  wVersionRequested = MAKEWORD( 1, 1 ); 
  err = WSAStartup( wVersionRequested, &wsaData ); 
  if ( err != 0 ) {  
    return; 
  }  
  if ( LOBYTE( wsaData.wVersion ) != 1 ||     
      HIBYTE( wsaData.wVersion ) != 1 ) {  
    WSACleanup( ); 
    return;
  }  
  SOCKET sockClient=socket(AF_INET,SOCK_STREAM,0);  
  SOCKADDR_IN addrSrv; 
  addrSrv.sin_addr.S_un.S_addr=inet_addr("127.0.0.1"); 
  addrSrv.sin_family=AF_INET; 
  addrSrv.sin_port=htons(6000); 
  connect(sockClient,(SOCKADDR*)&addrSrv,sizeof(SOCKADDR));  
  send(sockClient,"hello",strlen("hello")+1,0);  
  char recvBuf[50];  
  recv(sockClient,recvBuf,50,0);
  printf("%s\n",recvBuf);
  closesocket(sockClient); 
  WSACleanup(); 
}

服务端怎么提高处理socket连接的性能？

参考回答

提高处理socket连接的性能，请遵循以下技巧：

  1. 最小化报文传输的延时。
  2. 最小化系统调用的负载。
  3. 为 Bandwidth Delay Product 调节 TCP 窗口。
  4. 动态优化 GNU/Linux TCP/IP 栈。

答案解析

  1. 最小化报文传输的延时。

    在通过 TCP socket 进行通信时，数据都拆分成了数据块，这样它们就可以封装到给定连接的 TCP payload（指 TCP 数据包中的有效负荷）中了。TCP payload 的大小取决于几个因素（例如最大报文长度和路径），但是这些因素在连接发起时都是已知的。为了达到最好的性能，我们的目标是使用尽可能多的可用数据来填充每个报文。当没有足够的数据来填充 payload 时（也称为最大报文段长度（maximum segment size）或 MSS），TCP 就会采用 Nagle 算法自动将一些小的缓冲区连接到一个报文段中。这样可以通过最小化所发送的报文的数量来提高应用程序的效率，并减轻整体的网络拥塞问题。

  2. 最小化系统调用的负载。

    任何时候通过一个 socket 来读写数据时，都是在使用一个系统调用（system call）。这个调用（例如 read 或 write）跨越了用户空间应用程序与内核的边界。另外，在进入内核之前，该调用会通过 C 库来进入内核中的一个通用函数（system_call()）。从 system_call()中，这个调用会进入文件系统层，内核会在这儿确定正在处理的是哪种类型的设备。最后，调用会进入 socket 层，数据就是在这里进行读取或进行排队从而通过 socket 进行传输的（这涉及数据的副本）。

    这个过程说明系统调用不仅仅是在应用程序和内核中进行操作的，而且还要经过应用程序和内核中的很多层次。这个过程耗费的资源很高，因此调用次数越多，通过这个调用链进行的工作所需要的时间就越长，应用程序的性能也就越低。由于我们无法避免这些系统调用，因此唯一的选择是最小化使用这些调用的次数。

  3. 为 Bandwidth Delay Product 调节 TCP 窗口。

    TCP 的性能取决于几个方面的因素。两个最重要的因素是链接带宽（link bandwidth）（报文在网络上传输的速率）和 往返时间（round-trip time） 或 RTT（发送报文与接收到另一端的响应之间的延时）。这两个值确定了称为 Bandwidth Delay Product（BDP）的内容。

    给定链接带宽和 RTT 之后，就可以计算出 BDP 的值了，不过这代表什么意义呢？BDP 给出了一种简单的方法来计算理论上最优的 TCP socket 缓冲区大小（其中保存了排队等待传输和等待应用程序接收的数据）。如果缓冲区太小，那么 TCP 窗口就不能完全打开，这会对性能造成限制。如果缓冲区太大，那么宝贵的内存资源就会造成浪费。如果设置的缓冲区大小正好合适，那么就可以完全利用可用的带宽。

  4. 动态优化 GNU/Linux TCP/IP 栈。

    标准的 GNU/Linux 发行版试图对各种部署情况都进行优化。这意味着标准的发行版可能并没有对现有的环境进行特殊的优化。GNU/Linux 提供了很多可调节的内核参数，可以使用这些参数为自己的操作系统进行动态配置。

介绍一下流量控制和拥塞控制。

参考回答

  1. 流量控制和拥塞控制定义

    流量控制

    如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。流量控制就是让发送方慢点，要让接收方来得及接收。

    拥塞控制

    拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

  2. 流量控制和拥塞控制区别

    流量控制是端到端的控制，例如A通过网络给B发数据，A发送的太快导致B没法接收(B缓冲窗口过小或者处理过慢)，这时候的控制就是流量控制，原理是通过滑动窗口的大小改变来实现。

    拥塞控制是A与B之间的网络发生堵塞导致传输过慢或者丢包，来不及传输。防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不至于过载。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络性能有关的所有因素。

  3. TCP流量控制解决方法

    TCP的流量控制是利用滑动窗口机制实现的，接收方在返回的数据中会包含自己的接收窗口的大小，以控制发送方的数据发送。

  4. TCP拥塞控制解决方法

    TCP拥塞控制的四种算法：慢开始、拥塞避免、快重传、快恢复。

    （1）慢开始算法：当主机开始发送数据时，并不清楚网络的负载情况，所以由小到大逐渐增大拥塞窗口，每经过一个传输轮次没有出现超时就将拥塞窗口加倍。同时还需要设置一个慢开始门限，在拥塞窗口小于慢开始门限时使用慢开始算法，大于慢开始门限时，使用拥塞避免算法；

    （2）拥塞避免算法：在拥塞窗口大于慢开始门限时，让拥塞窗口按线性规律缓慢增长。即每经过一个传输轮次，拥塞窗口增大一个MSS最大报文段尺寸。（拥塞避免并非完全能够避免拥塞，只是使网络比较不容易出现拥塞）

    （3）快重传算法：使发送方今早知道发生了个别报文段丢失，并不是出现网络拥塞。

    要求接受不要登塞自己发送数据时才进行捎带确认，而是立即发送确认，即使收到了失序的报文段也要立即发出对已收到报文段的重复确认。而发送方一旦受到三个连续的重读确认，就将相应的报文段立即重传。

    （4）快恢复算法：发送方知道只有个别报文段丢失而不是网络拥塞时，不启动慢开始算法，而是执行快恢复算法，将慢开始门限和拥塞窗口值调整为当前窗口的一半，开始执行拥塞避免算法

答案解析

无

对路由协议是否有所了解？

参考回答

有了解。

  1. 路由协议定义

    路由协议（英语：Routing protocol）是一种指定数据包转送方式的网上协议。Internet网络的主要节点设备是路由器，路由器通过路由表来转发接收到的数据。转发策略可以是人工指定的（通过静态路由、策略路由等方法）。在具有较小规模的网络中，人工指定转发策略没有任何问题。但是在具有较大规模的网络中（如跨国企业网络、ISP网络），如果通过人工指定转发策略，将会给网络管理员带来巨大的工作量，并且在管理、维护路由表上也变得十分困难。为了解决这个问题，动态路由协议应运而生。动态路由协议可以让路由器自动学习到其他路由器的网络，并且网络拓扑发生改变后自动更新路由表。网络管理员只需要配置动态路由协议即可，相比人工指定转发策略，工作量大大减少。

  2. 原理

    路由协议通过在路由器之间共享路由信息来支持可路由协议。路由信息在相邻路由器之间传递，确保所有路由器知道到其它路由器的路径。总之，路由协议创建了路由表，描述了网络拓扑结构；路由协议与路由器，执行路由选择和数据包转发功能。

  3. 路由器的作用以及常见的路由协议

    路由协议主要运行于路由器上，路由协议是用来确定到达路径的，起到一个地图导航，负责找路的作用。它工作在网络层。它包括RIP，IGRP（Cisco私有协议），EIGRP（Cisco私有协议），OSPF，IS-IS，BGP。以下为这六个协议的详细说明：

    （1）RIP（路由信息协议）

    RIP很早就被用在Internet上，是最简单的路由协议。它是“路由信息协议（Route Information Protocol）”的简写，主要传递路由信息，通过每隔30秒广播一次路由表，维护相邻路由器的位置关系，同时根据收到的路由表信息计算自己的路由表信息。RIP是一个距离矢量路由协议，最大跳数为15跳，超过15跳的网络则认为目标网络不可达。此协议通常用在网络架构较为简单的小型网络环境。分为RIPv1和RIPv2两个版本，后者支持VLSM技术以及一系列技术上的改进。RIP的收敛速度较慢。

    （2）IGRP（内部网关路由协议）

    IGRP协议是“内部网关路由协议（Interior Gateway Routing Protocol）”的缩写，由Cisco于二十世纪八十年代独立开发，属于Cisco私有协议。IGRP和RIP一样，同属距离矢量路由协议，因此在诸多方面有着相似点，如IGRP也是周期性的广播路由表，也存在最大跳数（默认为100跳，达到或超过100跳则认为目标网络不可达）。IGRP最大的特点是使用了混合度量值，同时考虑了链路的带宽、延迟、负载、MTU、可靠性5个方面来计算路由的度量值，而不像其他IGP协议单纯的考虑某一个方面来计算度量值。IGRP已经被Cisco独立开发的EIGRP协议所取代，版本号为12.3及其以上的Cisco IOS（Internetwork Operating System）已经不支持该协议，已经罕有运行IGRP协议的网络。

    （3）EIGRP（增强型内部网关路由协议）

    由于IGRP协议的种种缺陷以及不足，Cisco开发了EIGRP协议（增强型内部网关路由协议）来取代IGRP协议。EIGRP属于高级距离矢量路由协议（又称混合型路由协议），继承了IGRP的混合度量值，最大特点在于引入了非等价负载均衡技术，并拥有极快的收敛速度。EIGRP协议在Cisco设备网络环境中广泛部署。

    （4）OSPF（开放式最短路径优先）

    OSPF协议是“开放式最短路径优先（Open Shortest Path First）”的缩写，属于链路状态路由协议。OSPF提出了“区域（area）”的概念，每个区域中所有路由器维护着一个相同的链路状态数据库（LSDB）。区域又分为骨干区域（骨干区域的编号必须为0）和非骨干区域（非0编号区域），如果一个运行OSPF的网络只存在单一区域，则该区域可以是骨干区域或者非骨干区域。如果该网络存在多个区域，那么必须存在骨干区域，并且所有非骨干区域必须和骨干区域直接相连。OSPF利用所维护的链路状态数据库，通过最短路径优先算法（SPF算法）计算得到路由表。OSPF的收敛速度较快。由于其特有的开放性以及良好的扩展性，OSPF协议在各种网络中广泛部署。

    （5）IS-IS（中间系统到中间系统）

    IS-IS协议是Intermediate system to intermediate system（中间系统到中间系统）的缩写，属于链路状态路由协议。标准IS-IS协议是由国际标准化组织制定的ISO/IEC 10589:2002所定义的，标准IS-IS不适合用于IP网络，因此IETF制定了适用于IP网络的集成化IS-IS协议（Integrated IS-IS）。和OSPF相同，IS-IS也使用了“区域”的概念，同样也维护着一份链路状态数据库，通过最短生成树算法（SPF）计算出最佳路径。IS-IS的收敛速度较快。集成化IS-IS协议是ISP骨干网上最常用的IGP协议。

    （6）BGP（边界网关协议）

    为了维护各个ISP的独立利益，标准化组织制定了ISP间的路由协议BGP。BGP是“边界网关协议（Border Gateway Protocol）”的缩写，处理各ISP之间的路由传递。但是BGP运行在相对核心的地位，需要用户对网络的结构有相当的了解，否则可能会造成较大损失。

答案解析

无

直播可能需要使用到什么样的协议？

参考回答

视频直播有多种协议，使用rtmp协议的就是rtmp直播。直播流就是视频流，即传递的视频数据。常见的协议有RTMP、RTSP、HTTP协议，这三个协议都属于互联网TCP/IP五层体系结构中应用层的协议。理论上这三种都可以用来做视频直播或点播。但通常来说，直播一般用RTMP、RTSP，而点播用HTTP。下面分别介绍下三者的特点。

  1. RTMP协议

    （1）是流媒体协议；

    （2）RTMP协议是Adobe的私有协议，未完全公开；

    （3）RTMP协议一般传输的是flv，f4v格式流；

    （4）RTMP一般在TCP1个通道上传输命令和数据。

  2. RTSP协议

    （1）是流媒体协议；

    （2）RTSP协议是共有协议，并有专门机构做维护；

    （3）RTSP协议一般传输的是ts、mp4格式的流；

    （4）RTSP传输一般需要2-3个通道，命令和数据通道分离。

  3. HTTP协议

    （1）不是是流媒体协议；

    （2）HTTP协议是共有协议，并有专门机构做维护；

    （3）HTTP协议没有特定的传输流；

    （4）HTTP传输一般需要2-3个通道，命令和数据通道分离。

答案解析

扩展资料

一个完整的视频直播过程，包括采集、处理、编码、封装、推流、传输、转码、分发、解码、播放等。

  1. 采集

    音频采集音频的采集过程主要通过设备将环境中的模拟信号采集成 PCM 编码的原始数据，然后编码压缩成 MP3 等格式的数据分发出去。常见的音频压缩格式有：MP3，AAC，HE-AAC，Opus，FLAC，Vorbis (Ogg)，Speex 和 AMR等。

    图像采集 图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据分发出去。常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。

  2. 处理

    视频或者音频完成采集之后得到原始数据，为了增强一些现场效果或者加上一些额外的效果，我们一般会在将其编码压缩前进行处理。

    视频：美颜、水印、路径、自定义。

    音频：混音、降噪、特效、自定义。

  3. 编码

    对流媒体传输来说，编码非常重要，它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。

    常见的视频编码器：

    （1）H.264/AVC

    （2）HEVC/H.265

    （3）VP8

    （4）VP9

    （5）FFmpeg

    音频编码器：Mp3, AAC等。

  4. 封装

    把编码器生成的多媒体内容(视频，音频，字幕，章节信息等)混合封装在一起几种常见的封装格式：

    （1）AVI 格式(后缀为 .avi)

    （2）DV-AVI 格式(后缀为 .avi)

    （3）QuickTime File Format 格式(后缀为 .mov)

    （4）MPEG 格式(文件后缀可以是 .mpg .mpeg .mpe .dat .vob .asf .3gp .mp4等)

    （5）WMV 格式(后缀为.wmv .asf)

    （6）Real Video 格式(后缀为 .rm .rmvb)

    （7）Flash Video 格式(后缀为 .flv)

    （8）Matroska 格式(后缀为 .mkv)

    （9）MPEG2-TS 格式 (后缀为 .ts)

    目前，我们在流媒体传输，尤其是直播中主要采用的就是 FLV 和 MPEG2-TS 格式，分别用于 RTMP/HTTP-FLV 和 HLS 协议。

  5. 推流

    推流是指使用推流工具等内容抓取软件把直播内容传输到服务器的过程。推送协议主要有三种：

    （1）RTSP(Real Time Streaming Protocol)：实时流传送协议，是用来控制声音或影像的多媒体串流协议, 由Real Networks和Netscape共同提出的;

    （2）RTMP(Real Time Messaging Protocol)：实时消息传送协议，是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议;

    （3）HLS(HTTP Live Streaming)：是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议;RTMP是目前主流的流媒体传输协议，广泛用于直播领域，市面上绝大多数的直播产品都采用了这个协议。

    RTMP协议基于 TCP，是一种设计用来进行实时数据通信的网络协议，主要用来在 flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括 Adobe Media Server/Ultrant Media Server/red5 等。它有三种变种：

    （1）RTMP工作在TCP之上的明文协议，使用端口1935；

    （2）RTMPT封装在HTTP请求之中，可穿越防火墙;

    （3）RTMPS类似RTMPT，但使用的是HTTPS连接;

    RTMP协议就像一个用来装数据包的容器，这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据。一个单一的连接可以通过不同的通道传输多路网络流。这些通道中的包都是按照固定大小的包传输的。

  6. 传输

    推送出去的流媒体需要传输到观众，整个链路就是传输网络。

  7. 转码

    视频直播播流端的码率是根据推流端决定的，即播流端的码率是与推流端的码率一致的。但是遇到以下场景会造成直播效果较差：推流端码率与播流端带宽不相匹配。当推流端码率较高而客户端带宽资源有限就会导致播放出现卡顿，而当推流端码率较低但是客户端对于直播效率要求较高时会导致播放效果较差。播放器插件需要实现多码率切换。前端播放器插件常可以设置码率切换，这就需要同一路推流可以同时提供多种码率的播流地址。因此，视频直播提供了实时转码功能对同一路推流地址同时提供多路不同码率播流地址提供服务。

  8. 分发

    流媒体服务器的作用是负责直播流的发布和转播分发功能。

  9. 解码

    编码器(Encoder)：压缩信号的设备或程序；

    解码器(Decoder)：解压缩信号的设备或程序；

    编解码器(Codec)：编解码器对。

  10. 播放器流播放主要是实现直播节目在终端上的展现。因为这里使用的传输协议是RTMP， 所以只要支持 RTMP 流协议的播放器都可以使用。

谈谈单工、双工、半双工的通信方式。

参考回答

  1. 单工：数据传输只支持数据在一个方向上传输；在同一时间只有一方能接受或发送信息，不能实现双向通信。举例：电视，广播。
  2. 半双工：半双工数据传输允许数据在两个方向上传输,但是,在某一时刻,只允许数据在一个方向上传输,它实际上是一种切换方向的单工通信；在同一时间只可以有一方接受或发送信息，可以实现双向通信。举例：对讲机。
  3. 双工：全双工数据通信允许数据同时在两个方向上传输,因此,全双工通信是两个单工通信方式的结合,它要求发送设备和接收设备都有独立的接收和发送能力；在同一时间可以同时接受和发送信息，实现双向通信。举例：电话通信。

答案解析

扩展资料：

单工、半双工和全双工是电信计算机网络中的三种通信信道。这些通信信道可以提供信息传达的途径。通信信道可以是物理传输介质或通过多路复用介质的逻辑连接。物理传输介质是指能够传播能量波的材料物质，例如数据通信中的导线。并且逻辑连接通常指电路交换连接或分组模式虚拟电路连接，例如无线电信通道。由于通信信道的帮助，信息可以无障碍地传输。

单工模式一般用在只向一个方向传输数据的场合。例如计算机与打印机之间的通信是单工模式，因为只有计算机向打印机传输数据，而没有相反方向的数据传输。还有在某些通信信道中，如单工无线发送等。

来源：https://www.nowcoder.com/tutorial/94/ea1986fcff294f6292385703e94689e8