计算机网络面试

一. 网络基础知识讲解

1.1 网络协议

• 当前世面上主要存在的几种协议： 四层， 五层 ， 七层
• OSI开放式协议是主流协议[七层]

1.2 七层协议：

• 第一层 物理层：
  • 机械、电子、定时接口通信道上的原始比特流传输
  • 功能：以二进制数据形式在物理媒体上传输数据
• 第二层 数据链路层：
  • 物理寻址，同时将原始比特流变为逻辑传输线路
  • 功能： 传输有地址的帧以及错误检测功能
• 第三层 网络层：
  • 控制子网的运行，如逻辑编址，分组传输、路由选择；
  • 功能：为数据包选择路由
• 第四层 传输层：
  • 接收上一层的数据，在必要的时候把数据进行分隔，并将这些数据交给网络层，且保证这些数据段有效到达对端；
  • 提供端对端的接口
• 第五层 会话层
  • 不同机器上的用户之间建立及管理会话
  • 功能：解除或建立与别的接点的联系
• 第六层 表示层
  • 信息的语法语义以及它们之间的关联，如加密解密、转换翻译、压缩解压密；
  • 功能： 数据格式化，代码转换，数据加密
• 第七层 应用层
  • 功能： 文件传输、电子邮件、文件服务、虚拟终端

TCP/IP不是完全遵从OSI七层模型，但它是OSI的一个实现；
平时的HTTP,HTTPS等的请求协议就是应用层；而TCP、UDP则是传输层，IP等为网络层等等；
TCP/IP的发送消息步骤是：先自上而下，后自下而上处理数据头部；发送消息的先从应用层封装，一直到底层然后开始发送；而接收方则是底层先开始接收，然后接收到后从链路层开始层层网上；如图所示：

OSI七层模型：

TCP/IP五层模型：

1.3、各层工作的设备

网关工作在第四层传输层及其以上

网络层：路由器

数据链路层：网桥，交换机

物理层：网卡，网线，集线器，中继器，调制解调器

1. 网关：应用层、传输层（网关在传输层上以实现网络互连，是最复杂的网络互连设备，仅用于两个高层协议不同的网络互连。网关的结构也和路由器类似，不同的是互连层。网关既可以用于广域网互连，也可以用于局域网互连）
2. 路由器：网络层（路由选择，存储转发）
3. 交换机：数据链路层、网络层（识别数据包中的MAC地址信息，根据MAC地址进行转发，并将这些MAC地址与对应的端口记录在自己内部的一个地址表中）
4. 网桥：数据链路层（将两个LAN连起来，根据MAC地址来转发帧）
5. 集线器（Hub）：物理层（纯硬件设备，主要用来连接计算机等网络终端）
6. 中继器：物理层（在比特级别对网络信号进行再生和重定时，从而使得它们能够在网络上传输更长的距离）

1.4、各层常见的协议

（1）、应用层: (典型设备:应用程序，如FTP，SMTP ，HTTP)

**DHCP(Dynamic Host Configuration Protocol)**动态主机分配协议，使用 UDP 协议工作，主要有两个用途：给内部网络或网络服务供应商自动分配 IP 地址，给用户或者内部网络管理员作为对所有计算机作中央管理的手段。实 现即插即用连网。

**FTP （File Transfer Protocol）**文件传输协议<端口号21>减少或消除不同操作系统下处理文件的不兼容性。

**HTTP （Hypertext Transfer Protocol ）**超文本传输协议 <端口号 80>， 面向事务的应用层协议

**SMTP （Simple Mail Transfer Protocol ）**简单邮件传输协议 <端口号25> 用于发送邮件。

RPC （Remote Procedure Call Protocol ）（RFC- 1831）远程过程调用协 议

PING 、Telnet、DNS（Domin name system）

（2）传输层: (典型设备: 进程和端口) 数据单元：数据段 （Segment）

**TCP （Transmission Control Protocol ）**传输控制协议提供可靠的面向连接的服务，传输数据前须先建立连接，结束后释放。可靠的全双工信道。可靠、有序、无丢失、不重复。

**UDP (User Datagram Protocol ）**用户数据报协议发送数据前无需建立连接，不使用拥塞控制，不保证可靠交付，最大努力交付。

（3）网络层: (典型设备:路由器，防火墙、多层交换机) 数据单元：数据包（Packet ）

IP (IPv4 · IPv6) (Internet Protocol) 网络之间互连的协议

ARP (Address Resolution Protocol) 即地址解析协议，实现通过IP 地址得 知其物理地址。

**RARP (Reverse Address Resolution Protocol)**反向地址转换协议允许局域 网的物理机器从网关服务器的 ARP 表或者缓存上请求其 IP地址。

**ICMP (Internet Control Message Protocol ）**Internet 控制报文协议。它是TCP/IP 协议族的一个子协议，用于在IP 主机、路由器之间传递控制消息。

ICMPv6 :

IGMP (Internet Group Management Protocol) Internet 组管理协议,是因特 网协议家族中的一个组播协议，用于 IP 主机向任一个直接相邻的路由器报 告他们的组成员情况。

（4）数据链路层: (典型设备: 网卡，网桥，交换机) 数据单元：帧 （Frame）

**PPP(Point-to-Ponit Protocol)**点对点协议面向字节，由三部分组成：一个将IP 数据报封装到串行链路的方法；一个用于建立、配置和测试数据链路连接的链路控制协议

停止等待协议：
**CSMA/CD(Carrrier Sense Multiple Access with Collision Detection)**载波监听多点接入/碰撞检测协议。总线型网络，协议的实质是载波监听和碰撞检测。载波监听即发数据前先检测总线上是否有其他计算机在发送数据，如暂时不发数据，避免碰撞。碰撞检测为计算机边发送数据边检测信道上的信号电压大小。

**ARQ（Automatic Repeat-reQuest ）**自动重传请求协议，错误纠正协议之一，包括停止等待ARQ 协议和连续ARQ 协议，错误侦测、正面确认、逾时重传与负面确认继以重传等机制。

（5）、物理层:(典型设备：中继器，集线器、网线、HUB) 数据单元：比特 （Bit）

以太网物理层、调制解调器、PLC 、SONET/SDH 、G.709 、光导纤维、 同轴电缆、双绞线

1.5、路由器与交换机的主要区别

（1）工作层次不同

最初的的交换机是工作在数据链路层，而路由器一开始就设计工作在网络层。由于交换机工作在数据链路层，所以它的工作原理比较简单，而路由器工作在网络层，可以得到更多的协议信息，路由器可以做出更加智能的转发决策。

（2）数据转发所依据的对象不同

**交换机是利用物理地址或者说MAC地址来确定转发数据的目的地址。而路由器则是利用IP地址来确定数据转发的地址。**IP地址是在软件中实现的，描述的是设备所在的网络。MAC地址通常是硬件自带的，由网卡生产商来分配的，而且已经固化到了网卡中去，一般来说是不可更改的。而IP地址则通常由网络管理员或系统自动分配。

（3）传统的交换机只能分割冲突域，不能分割广播域；而路由器可以分割广播域

由交换机连接的网段仍属于同一个广播域，广播数据包会在交换机连接的所有网段上传播，在某些情况下会导致通信拥挤和安全漏洞。连接到路由器上的网段会被分配成不同的广播域，广播数据不会穿过路由器。虽然第三层以上交换机具有VLAN功能，也可以分割广播域，但是各子广播域之间是不能通信交流的，它们之间的交流仍然需要路由器。

（4）路由器提供了防火墙的服务

路由器仅仅转发特定地址的数据包，不传送不支持路由协议的数据包传送和未知目标网络数据包的传送，从而可以防止广播风暴

二. TCP

2.1传输控制协议TCP简介

• 在TCP/IP中，IP负责定位接收方位置，而TCP则负责传输的可靠性；
• TCP传输协议的特点：
  • 面向连接的、可靠的、基于字节流的传输层通信协议；
  • 将应用层的数据流分割成报文段并发送给目标节点的TCP层；
  • 数据包都有序号，对方收到则发送ACK确认，未收到则重传
  • 使用校验和来检验数据在传输过程中是否有误；

进程号PID在一台计算机中是唯一的，但是在两台计算机通信过程中，只能使用端口号，因为可能PID会重复；

TCP通过哪些方式来保证可靠性？

1. 应用数据被分割成TCP认为最适合发送的数据块。
2. 确认机制，发送报文后，等待确认。
3. 重发机制，没有收到确认，将重发数据段。
4. 保持它首部和数据的校验和。确认数据的准确性。
5. 排序，丢弃重复的，流量控制。

2.2 TCP标志： TCP Flags

• URG： 紧急指针标志
• ACK： 确认序号标志
• PSH： push 标志
• RST： 重置连接标志
• SYN： 同步序号，用于建立连接过程
• FIN： finish标志，用于释放连接

2.3 TCP三次握手

2.3.1 三次握手的流详解：

• 第一次握手： 建立连接时，客户端发送SYN包（syn=j）到服务器，并进入SYN_SEND状态，等待服务器确认；
• 第二次握手： 服务器收到SYN包，必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态；
• 第三次握手： 客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1),此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手；

“握手” 是为了建立连接；

１.首先，客户机与服务器的TCP进程都处于CLOSED（关闭）状态，当要进行TCP连接时，客户机主动打开连接，服务器被动打开连接（这是因为服务请求总是由客户机向服务器发起，因为想要请求的资源都在服务器上，所以客户机想要获取资源就必须主动向服务器发起请求，而不能是等待服务器向自己（客户机）发起请求）。

２.然后，服务器的TCP进程先创建传输控制块TCB（传输控制块TCB存储了每一个连接中的重要信息，如：TCP连接表，指向发送和接收缓存的指针，指向重传队列的指针，当前的发送和接收序号，等等），此时，服务器就处于LISTEN（收听）状态。同样的，客户机也会首先创建一个传输控制块TCB发送给服务器。这样，准备工作就做好了。

３.现在就可以开始真正的三次握手了。首先，客户机先向服务器发送连接请求报文段，该报文段中将首部中的同步位SYN置为１（只有当SYN置为１时，才能表明客户机想要和服务器建立连接），并且随机选择一个初始序号ｘ，注意此时的SYN数据报中并没有携带数据，但是仍旧要消耗掉一个序号，此时客户机进入到SYN-SENT（同步已发送）状态。

４.此时，服务器收到客户机的请求时，如果同意与该客户机进行连接，则需要向客户机发送确认报文。在发送报文中需要将SYN与ACK都置为１（当ACK置为1时，表明服务器同意与客户机进行连接；同时将SYN置为1，表明服务器想要和客户机建立连接），并且随机选择一个初始序号y，确认号为x+1，注意此时的SYN数据报中并没有携带数据，但是也要消耗掉一个序号，此时TCP服务器进程进入到SYN-RCVD（同步收到）阶段。

​ 5.TCP客户端收到服务器的确认后，还要再向服务器给出确认。确认报文段中ACK置为1，确认号为ack=y+1(因为之前服务器给客户机发送的序号为y，因此现在客户机向服务器发送的确认号为ack=y+1，意思是客户机渴望收到的下一个报文段的第一个数据字节为y+1)此时客户机的发送序号为x+1

注意*：在进行第三次握手时，ACK报文段可以携带数据，也可以不携带数据，如果携带数据，则消耗一个序列，这样客户机下次发送报文段时的序号为x+2，如果不携带数据则不消耗序号，下次客户机发送报文段时的序号为x+1*。这时TCP连接已经建立，客户机和服务器都进入到ESTABLISHED（已建立连接）状态。

2.3.2 为什么需要三次握手才能建立连接？

• 为了初始化Sequence Number的初始值
• 首次握手的隐患： SYN超时
  • 问题起因分析：
    • Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认
    • Server不断重试直至超时，Linux默认等待63秒才断开连接

可能会因此收到攻击，恶意用户模拟发送数据然后下线，而没有接收方则会等待63秒才断开连接，会一直消耗SYN的队列；

答：这是为了防止已失效的连接请求报文段突然又传到了服务器。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常的情况，客户机发出连接请求，但因为连接请求报文丢失而未收到确认。于是客户机再重传了一次连接请求，后来收到了确认，建立了连接。数据传输完后，就释放了连接。客户机共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务器，没有所谓的“已失效的连接请求报文段”。

但是如果出现了一种异常情况，即客户机发出的第一个报文段并没有丢失，而是在某个节点上长时间滞留了，直至客户机向服务器发送了第二个报文段并且已经完成数据传输释放了连接，此时，第一个报文到达服务器后会被误以为是客户机重新发起的一次连接请求，实质上是一个早已失效的连接请求。如果没有第三次握手，那么这个连接就建立了，但是客户机并不会向服务器发送任何请求，这样连接就会一直持续，白白的消耗网络资源。

2.3.3 首次握手的隐患-- 连接超时

• 如果收到攻击怎么防护呢？
  • SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
  • 若为正常连接则Client会回发SYN Cookie，直至建立连接；

2.3.4 建立连接后，Client出现故障怎么办

• 保活机制：
  • 向对方发送保活探测报文，如果未收到响应则继续发送；
  • 尝试册数达到保活探测数认为收到响应则中断连接；

2.4. TCP的四次挥手

2.4.1 为什么要四次挥手？

• “挥手”是为了终止连接
• 确保数据能够完成传输，但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你；但未必你所有的数据都全部发送给对方了，所以你可以马上马上关闭SOCKET，即你可能还需要发哦送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

2.4.2 TCP四次挥手的流程图：

2.4.3 四次挥手的解析：

• TCP采用四次挥手来释放连接
• 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态；
• 第二次挥手：Server收到FIN后，发送一个ACK给Client,确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态；
• 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；
• 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手；

简单来讲，客户端第一次挥手是自己中断到服务端的数据传送，然后告诉服务端；第二次挥手是服务端接收到信息后进入等待关闭状态；第三次挥手是服务端关闭到客户端的数据传送，然后告诉客户端；第四次挥手是客户端进入超时关闭，然后通知服务端，服务端接收到后立即关闭；

１.数据传输结束后，通信的双方都可以释放连接。此时，客户机和服务器都处于ESTABLISHED（已建立连接）状态。

２.假设客户机请求完资源了，想要释放连接。首先，客户机的应用进程先向服务器发出连接释放报文段，该报文段中将**首部的终止控制位FIN置为１（只有当FIN置为１时，才能表明客户机想要和服务器断开连接），并且序号为ｕ（注意：此时的ｕ不是随机产生的，而是之前客户机传送的数据的最后一个字节的序号加１）。此时客户机进入到FIN－WAIT－１（终止等待１）状态，等待服务器的确认。

３.服务器收到连接释放报文后发出确认，在发送报文中**将首部中的ACK置为１（ACK置为１，表面服务器同意与客户机释放连接），并且产生序号ｖ（注意：此时的v不是随机产生的，而是之前服务器传送的数据的最后一个字节的序号加１），并且发出确认号为u+１（确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号，因为之前发送了u，所以下一个序号为u+1）。**此时服务器就进入CLOSE－WAIT（关闭等待）状态，客户机进入FIN-WAIT-2状态。

​ **此时，从客户机到服务器这个方向的连接就被释放了，也就是说，客户机已经没有数据要向服务器发送了，但是如果服务器向客户机发送数据，客户机仍要接收数据。也就是说：从客户机到服务器的连接已经被释放了，但是从服务器到客户机的连接还没被释放。此时，**TCP连接处于半关闭状态。

​ 4.如果服务器向客户机也没有要发送的数据的话，那么服务器的应用进程就可以向客户机发出连接释放报文段（注意此时还是服务器向客户机发送数据），该报文段中将首部的**终止控制位FIN置为1（只有当FIN置为１时，才能表明客户机想要和服务器断开连接），ACK也置为1，并且序号为w（**重点注意，此时的w不一定等于v+1。如果在客户机释放了连接之后，服务器向客户机仍旧发送了一部分数据，那么此时w不等于v+1，但是如果期间没有再发送数据，那么w就等于v+1。总而言之，这个w等于服务器上一次发送的数据的最后一个字节加1），并且发送确认号为u+1（确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号，因为之前发送了u，所以下一个序号为u+1）。此时服务器就进入了LAST-ACK（最后确认）状态。

​ 5.客户机收到服务器的连接释放报文后，必须对此报文进行确认。在该报文段中将**ACK置为1，确认号为w+1（确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号，因为之前发送了w，所以下一个序号为w+1），产生序号为u+1（因为上一个发送的数据的序号为u）。**此时服务器进入到TIME-WAIT（等待时间）状态。但是，此时TCP连接还没有被释放掉。必须经过2MSL后服务器才能进入到CLOSED状态。（注：MSL叫做最长报文段寿命，RFC建议为两分钟，也就是说，要经过四分钟才能进入到CLOSED状态）。

2.4.4 为什么客户端不直接关闭，要有TIME_WAIT状态？

• 原因：
  • 确保有足够的时间让对方收到ACK包
  • 避免新旧连接混淆

答：第一：**为了保证客户机最后发送的那个ACK报文段能够到达服务器。这个ACK报文段可能会丢失。**因而使处在LAST-ACK状态的B收不到对已发送的FIN＋ACK报文段的确认。服务器会超时重传这个FIN＋ACK报文段，而客户机就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着客户机重传一次确认，重新启动2MSL计时器，最后客户机和服务器都可以进入到CLOSED（关闭）状态。如果没有2MSL等待时间，那么就无法收到重传的FIN+ ACK包，无法进入正常的CLOSED状态。

​ 第二，防止“已失效的连接请求报文段”出现在本连接中。客户机在发送完最后一个ACK报文段，再经过时间2MSL，就可以使本连接持续的时间内所产生的报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

2.4.5 为什么需要四次握手才能断开连接

• 原因：
  • 因为全双工，发送方和接收方都需要FIN报文和ACK报文；而每次的操作都是双方各执行一次，所以四次握手实际上是每个各执行两次；

2.4.6 服务器出现CLOSE_WAIT状态的原因？

• 原因：
  • 对方关闭socket连接，我方忙于读或写，没有及时关闭连接
    • 检查代码，特别是释放资源的代码
    • 检查配置，特别是处理请求的线程配置；
  • 如果: CLOSE_WAIT的数量达到上千，很有可能造成通道堵塞，新请求无法接受，抛出too many open files错误，并导致Nginx,Tomcat等的崩溃；

2.4.7 三次握手有什么缺陷可以被黑客利用，用来对服务器进行攻击？

**（1）SYN攻击（拒绝服务攻击）**就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。

解决方法：

第一种是缩短SYN Timeout时间；

由于SYN Flood 攻击的效果取决于服务器上保持的SYN半连接数，这个值=SYN攻击的频度 x SYN Timeout ，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃该连接的时间，例如设置为20秒以下（过低的SYN Timeout 设置可能会影响客户的正常访问），可以成倍地降低服务器的负荷。

第二种方法是设置 SYN Cookie；

就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击。以后从这个IP地址来的包会被丢弃。

可是上述的两种方法只能对付比较原始的SYN Flood攻击，缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP地址，如果攻击者以数万/秒的速度发送SYN报文，同时利用随机改写IP报文中的源地址，以上的方法将毫无用武之地。例如SOCK_RAW 返回的套接字通过适当的设置可以自己完全控制IP头的内容从而实现IP欺骗。

第三种方法是Syn Cache技术；

这种技术在收到SYN时不急着去分配系统资源，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配系统。

第四种方法是使用硬件防火墙；

SYN Flood攻击很容易就能被防火墙拦截。

（2）Land攻击

LAND攻击力用了TCP连接建立的三次握手过程，通过向一个目标主机发送一个用于建立请求连接的TCP SYN报文而实现对目标主机的攻击。**与正常的TCP SYN报文不同的是：LAND攻击报文的源IP地址和目的IP地址是相同的，都是目标主机的IP地址。**这样目标主机接在收到这个SYN报文后，就会向该报文的源地址发送一个ACK报文，并建立一个TCP连接控制结构，而该报文的源地址就是自己。由于目的IP地址和源IP地址是相同的，都是目标主机的IP地址，因此这个ACK报文就发给目标主机本身。这样如果攻击者发送了足够多的SYN报文，则目标计算机的TCB可能会耗尽，最终不能正常服务。

扩展：DDOS攻击的原理，如何防止DDOS攻击？

DDOS是英文Distributed Denial of Service 的缩写，意即“分布式拒绝服务”。

当下主要有2种流行的DDOS攻击：

1、SYN Flood攻击：这种攻击方法是经典最有效的DDOS方法。

2、TCP全连接攻击

这种攻击是为了绕过常规防火墙的检查而设计的，一般情况下，常规防火墙大多具备过滤Land等DOS攻击的能力，但对于正常的TCP连接时放过的，很多网络服务程序（如：IIS、Apache等Web服务器）能接受的TCP连接数是有限的，一旦有大量的TCP连接，则会导致网站访问非常缓慢甚至无法访问。

TCP全连接攻击就是通过许多僵尸主机不断地与受害服务器建立大量的TCP连接，直到服务器的内存等资源被耗尽而被拖垮，从而造成拒绝服务。

这种攻击的特点是可绕过一般防火墙的防护而达到攻击目的。

缺点是需要找很多僵尸主机，并且由于僵尸主机的IP是暴露的，因此容易被追踪。

如何防止呢？

1、限制SYN流量

用户在路由器上配置SYN的最大流量来限制SYN封包所能占有的最高频宽，这样，当出现大量的超过所限定的SYN流量时，说明不是正常的网络访问，而是有黑客入侵。

2、定期扫描

定期扫描现有的网络主节点，清查可能存在的安全漏洞，对新出现的漏洞及时进行清理。

3、在骨干节点配置防火墙

防火墙本山能抵御DDOS攻击和其他一些攻击。在发现受到攻击的时候，可以将攻击导向一些牺牲主机，这样可以保护真正的主机不被攻击。当然导向的这些牺牲主机可以选择不重要的，或者是Linux以及unix等漏洞少和天生防范攻击优秀的系统。

4、用足够的机器承受黑客攻击

这是一种较为理想的应对策略。如果用户拥有足够的容量和足够的资源给黑客攻击，在它不断访问用户、夺取用户资源之时，自己的能量也在逐渐耗失，或许未等用户被攻死，黑客已无力支招了。不过此方法需要投入的资金比较多，平时大多数设备处于空闲状态，和目前中小企业网络实际运行情况不相符。

5、过滤不必要的服务和端口

可以使用Inexpress、Express、Forwarding等工具来过滤不必要的服务和端口，即在路由器上过滤假IP。

2.5 TCP的滑动窗口（流量控制）

2.5.为什么要使用滑动窗口协议？

• 如果过多的源同时以很快的速度发送大量的数据包，而此时接收方并没有如此高的接收数据的能力，因此极易导致网络的拥塞。所以，为了控制发送方的发送速度，防止发送方并考虑到受发送缓冲区大小的制约等，要求对发送方已发出但尚未经确认的帧的数目加以限制，同时使网络的传输效率得到提高，滑动窗口协议应运而生，它使得发送方可以在未收到确认的情况下，同时发送多个数据分组，由此大大提升了网络吞吐量。
• 在任何基于自动重发请求进行错误控制的通信协议中，接收方必须确认收到的数据包。 如果发送方在合理的时间内没有收到确认，则重发数据。没有听到确认的发送方不知道接收方是否实际接收到分组（数据可能在传输中丢失或损坏）。 如果错误检测显示损坏，则数据包将被接收方忽略，并且不会发送确认。 因为网络传输的时延，将有大量时间被用于等待确认，导致传输效率低下。

2.6 RTT和RTO

• RTT: 发送一个数据包到收到对应的ACK，所花费的时间(相当于发送一次数据到接收的时间)
• RTO: 重传的时间间隔

2.7 滑动窗口原理：

图中可以看到，主要分为3个部分，第一部分为发送且已接收；第二部分为未发送且可发送；第三部分为未发送且溢出发送不了；
当第二部分的一部分数据已经发送过且确认过了，滑动窗口就会向右移动，将缓冲区的数据重新填充，溢出的数据则又在可发送的范围内；

2.6 TCP的拥塞控制机制

拥塞控制

​ 流量控制通过滑动窗口来实现，但是rwnd窗口只考虑了发送端和接收端的问题，没考虑网络的问题。有可能接收端很快，但是网络拥塞了，所以加了一个拥塞窗口（cwnd）。

​ 拥塞窗口的意思就是一次性可以连续提交多少个包到网络中。最终的形态是LastByteSent-LastByteAcked<=min(cwnd,rwnd)，由两个窗口共同控制发送速度。

​ TCP的拥塞控制主要避免两种现象，包丢失和包重传。网络的带宽是固定的，当发送端发送速度超过带宽后，中间设备处理不完多出来的包就会被丢弃，这就是包丢失。如果我们在中间设备上加上缓存，处理不过来的包就会被加到缓存队列中，不会丢失，但是会增加时延。如果时延到达一定的程度，就会超时重传，这就是包重传。

1. 慢启动（慢开始）：

• 慢开始不是指cwnd的增长速度慢（指数增长），而是指TCP开始发送设置cwnd=1。
• 思路：不要一开始就发送大量数据。先探测一下网络的拥塞程度，也就是所由小到大逐渐增加拥塞窗口的大小。这里用报文段的个数的拥塞窗口带下举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。
• 为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限（ssthresh状态变量）
• 当cwnd
• 当cwnd
• 当cwnd

2. 拥塞避免：

• 拥塞避免并非完全能够拥塞避免，是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使用网络比较不容易出现拥塞。
• 思路：让拥塞窗口cwnd缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口加1。

总结：
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如图所示：

3. 快速重传：

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

4. 快速恢复：

• 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，吧ssthresh门限减半。但是接下来并不执行慢开始算法。
• 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所有发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

2.7 KeepAlive

1.为什么要有KeepAlive？

​ 客户端向服务端发送 一个消息，服务端收到消息后一看，瞧给你牛*的，然后没理客户端，客户端一直在等待，但是不知道是不是服务器挂掉了？ 这时候TCP协议提出一个办法，当客户端端等待超过一定时间后自动给服务端发送一个空的报文， 如果对方回复了这个报文证明连接还存活着，如果对方没有报文返回且进行了多次尝试都是一样， 那么就认为连接已经丢失，客户端就没必要继续保持连接了。 如果没有这种机制就会有很多空闲的连接占用着系统资源。

2.怎么开启KeepAlive？

KeepAlive并不是默认开启的，在Linux系统上没有一个全局的选项去开启TCP的KeepAlive。需要开启KeepAlive的应用必须在TCP的socket中单独开启。Linux Kernel有三个选项影响到KeepAlive的行为：

• tcp_keepalive_time 7200// 距离上次传送数据多少时间未收到新报文判断为开始检测，单位秒，默认7200s
• tcp_keepalive_intvl 75// 检测开始每多少时间发送心跳包，单位秒，默认75s
• tcp_keepalive_probes 9// 发送几次心跳包对方未响应则close连接，默认9次

TCP socket也有三个选项和内核对应，通过setsockopt系统调用针对单独的socket进行设置：

• TCPKEEPCNT: 覆盖 tcpkeepaliveprobes
• TCPKEEPIDLE: 覆盖 tcpkeepalivetime
• TCPKEEPINTVL: 覆盖 tcpkeepalive_intvl

举个例子，以我的系统默认设置为例，kernel默认设置的tcpkeepalivetime是7200s, 如果我在应用程序中针对socket开启了KeepAlive,然后设置的TCP_KEEPIDLE为60，那么TCP协议栈在发现TCP链接空闲了60s没有数据传输的时候就会发送第一个探测报文。

3. KeepAlive的不足和局限性

其实，tcp自带的keepalive还是有些不足之处的。

**（1）keepalive只能检测连接是否存活，不能检测连接是否可用。**例如，某一方发生了死锁，无法在连接上进行任何读写操作，但是操作系统仍然可以响应网络层keepalive包。

（2）TCP keepalive 机制依赖于操作系统的实现,灵活性不够，默认关闭，且默认的 keepalive 心跳时间是 两个小时, 时间较长。

（3）代理(如socks proxy)、或者负载均衡器，会让tcp keep-alive失效

三. UDP

3.1 UDP的简介

• 面向非连接
• 不维护状态，支持同时向多个客户端传输相同的消息；
• 数据包报头只有8个字节(TCP有20个)，额外开销较小
• 吞吐量只受限于数据生成速率，传输速率以及机器性能
• 尽最大努力交付，不保证可靠交付，不需要位置复杂的链接状态表
• 面向报文，不对应用程序提交的报文信息进行拆分或者合并

UDP的速度很快，它只受限于机器的计算性能以及网络带宽速度的影响；它对于TCP而言，更快，但是容易丢失数据；存在一定的丢包率，不能保证所有数据一定会到达；

3.2 UDP报头字段和含义

源端口号（2） 目的端口号（2）
UDP长度：是UDP的报文总长度，是多余的。IP总长度减去首部长度就是此值。（2）
UDP校验和：校验和是可选的。（TCP是必选的）校验和和覆盖UDP首部和数据（TCP也一样覆盖首部和数据，但是IP指覆盖首部）（2）

UDP的校验和是怎么计算的？

​ UDP的校验和要计算首部和数据部分。首部还包括伪首部。

​ 多了12个字节的伪首部。
注意：UDP长度计算两次。如果校验和有错，则UDP数据报被悄悄丢弃，不产生任何差错报文。

为什么要加有伪首部？

​ 目的是让UDP两次检查数据是否已经到达正确目的地。IP接受正确的目的地址，传送到正确的上层程序。
​ 所有伪首部包括：源IP地址，目的IP地址，0，协议号，UDP长度。

四. TCP与UDP的区别

1、TCP和UDP的概念相互的区别及劣势

1. TCP面向连接，UDP面向无连接。
2. TCP面向字节流，UDP面向报文。
3. TCP提供可靠传输服务（数据顺序、正确性），UDP传输不可靠，尽最大努力进行交付。
4. TCP协议传输速度慢，UDP协议传输速度快。
5. TCP协议对系统资源要求多（头部开销大，有20个字节），UDP协议要求少（头部只有8个字节）。
6. 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

结论：
- 面向连接vs 无连接
- 可靠性
- 有序性
- 速度
- 量级

2、TCP、UDP为什么存在伪报头？

​ UDP（TCP）校验和：是根据UDP（TCP）数据报和伪报头计算得到的差错检测值。
伪报头包含源和目的IP地址，以及来自IP数据报报头的协议值。IP数据报在网络中传送时包含UDP数据报。伪报头并不会在网络中传送，校验和所包含的伪报头内容可以避免目的端错误地接受错误路由的数据报。校验和值的计算方法和IP报头校验和的计算方法类似。

五. HTTP协议

6.1 HTTP主要特点

• 支持客户/服务器模式： 请求/响应
• 简单快速：请求方法有GET,POST等，方式简单，程序小，速度快；
• 灵活：允许传输任意类型的对象
• 无连接：限制每次连接只处理一个请求，处理完成后就断开连接
• 无状态：协议对事务处理没有记忆能力，对同一个url请求没有上下文关系，每次的请求都是独立的，服务器中没有保存客户端的状态，必须带上状态去访问服务器；

6.2 HTTP请求结构

6.3 HTTP响应结构

6.4 请求/响应的步骤：

• 客户端连接到WEB服务器
• 发送HTTP请求
• 服务器接收请求并返回HTTP响应
• 释放连接TCP连接
• 客户端浏览器解析HTML内容

6.5 在浏览器地址栏键入URL，按下回车之后经历的流程

• 答：

  根据域名找到对应的ip地址

  1. DNS解析：逐层查询缓存是否存在该地址对应ip： 从近到远： 浏览器缓存，系统缓存，路由器缓存,IPS服务器缓存，域名服务器缓存，顶级域名服务器缓存，如果中间查到了则直接返回，不再继续查询
  2. TCP连接
  3. 发送HTTP请求
  4. 服务器处理请求并返回HTTP报文
  5. 浏览器解析渲染页面
  6. 连接结束

6.6 HTTP状态码

• 五种可能的取值：
  • 1xx： 指示信息–表示请求已接收，继续处理
  • 2xx： 成功-- 表示请求已被成功接收、理解、接受；
  • 3xx： 重定向-- 要完成请求必须进行进一步的操作；
  • 4xx： 客户端错误–请求有语法错误或请求无法实现；
  • 5xx： 服务器端错误-- 服务器未能实现合法的请求；
• 常见状态码：
  • 200 OK ： 正常返回信息
  • 400 Bad Request: 客户端请求有语法错误，不能被服务器所理解
  • 401 Unauthorized: 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
  • 403 Forbidden: 服务器收到请求，但是拒绝提供服务
  • 404 Not Found: 请求资源不存在，eg,输入了错误的URL
  • 500 Internal Server Error ： 服务器发送不可预期的错误
  • 503 Server Unavailable: 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

6.7 GET请求和POST请求的区别

• 从三个层面来回答：
  • HTTP报文层面：GET将请求信息放在URL，POST放在报文体中；
  • 数据库层面： GET符合幂等性和安全性，POST不符合；
  • 其他层面：GET可以被缓存，被存储，而POST不行；

GET请求直接将请求路径等在URL地址中，容易造成部分信息暴露，相对来讲"不安全"；且体积有限制，POST不限制大小；
数据库方面，GET请求多用于查询，所以一般不会造成数据的改变，而POST的请求多用于修改添加等操作，数据库的相关数据会变化；
GET请求的数据被缓存可以减轻服务器压力；

GET/POST

1、get与post的区别

• GET在浏览器回退时是无害的，而POST会再次提交请求。

• GET产生的URL地址可以被Bookmark，而POST不可以。

• GET请求会被浏览器主动cache，而POST不会，除非手动设置。

• GET请求只能进行url编码，而POST支持多种编码方式。

• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• GET请求在URL中传送的参数是有长度限制的，而POST么有。

• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

• GET参数通过URL传递，POST放在Request body中。

• GET产生一个TCP数据包；POST产生两个TCP数据包。并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

  对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

  而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

6.8 Cookie和Session 的区别？

• Cookie简介：
  • 是由服务器发给客户端的特殊信息，以文本的形式存放在客户端
  • 客户端再次请求的时候，会把Cookie回发
  • 服务器接收到后，会解析Cookie生成与客户端相对应的内容
• Session简介
  • 服务器端的机制，在服务器上保存的信息
  • 解析客户端请求并操作session id ，按需保存状态信息
• Session的实现方式：
  • 使用cookie来实现
  • URL回写 [如果cookie被禁用，则通过此方式实现]

总结：

• Cookie数据存放在客户的浏览器上，Session数据放在服务器上
• Session相对于Cookie更安全
• 若考虑减轻服务器负担，应当使用Cookie；

六. HTTP和HTTPS的区别？

7.1 SSL(Security Sockets Layer,安全套接层)

• 为网络通信提供安全以及数据完整性的一种安全协议
• 是操作系统对外的API，SSL3.0后更名为TLS
• 采用身份验证和数据加密保证网络通信安全和数据的完整性；

7.2 加密的方式：

• 对称加密： 加密和解密都使用同一个密钥
• 非对称加密： 加密使用的密钥和解密使用的密钥是不相同的；
• 哈希算法： 将任意长度的信息转换为固定长度的值，算法不可逆；
• 数字签名： 证明某个消息或者文件是某人发出/认同的；

7.3 HTTPS数据传输流程：

1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

服务器将公钥发送给客户端，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BAapk8vE-1609293035544)(D:\document\youdaoyun\qqE83DCA9D5B3F030AF9AB2979E3B9D1B8\c923a1c8f1634c8997cdb4eb27af2427\clipboard.png)]

服务器端的公钥和私钥，用来进行非对称加密

客户端生成的随机密钥，用来进行对称加密

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

1.客户端向服务器发起HTTPS请求，连接到服务器的443端口

2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

3.服务器将自己的公钥发送给客户端。

4.客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。

7.然后服务器将加密后的密文发送给客户端。

**8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。**这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

7.4 总结： HTTPS与HTTP区别？

• HTTPS 需要到CA申请证书，HTTP不需要
• HTTPS密文传输，HTTP明文传输
• 连接方式不同，HTTPS默认使用443端口，HTTP使用80端口
• HTTPS=HTTP+加密+认证+完整性保护，较HTTP安全；

7.5 HTTPS真的很安全吗？

• 浏览器默认填充http://，请求需要进行跳转，有被劫持的风险；
• 可以使用HSTS（HTTP Strict Transport Security）优化；

7.6 Keepalive

1、背景

KeepAlive是就是通常所称的长连接。KeepAlive带来的好处是可以减少tcp连接的开销，这对于短response body的请求效果更加明显。同时，可以为采用HTTP协议的交互式应用提供良好的session支持。

2、KeepAlive的原理

在HTTP1.0和HTTP1.1协议中都有对KeepAlive的支持。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能够支持，而HTTP1.1默认支持。

HTTP1.0 KeepAlive支持的数据交互流程如下：

a)Client发出request，其中该request的HTTP版本号为1.0。同是在request中包含一个header：”Connection： keep-alive“。

b)Web Server收到request中的HTTP协议为1.0及”Connection： keep-alive“就认为是一个长连接请求，其将在response的header中也增加”Connection： keep-alive“。同是不会关闭已建立的tcp连接。

c)Client收到Web Server的response中包含”Connection： keep-alive“，就认为是一个长连接，不close tcp连接。并用该tcp连接再发送request。（跳转到a)）

HTTP1.1 KeepAlive支持的数据交互流程如下：

a)Client发出request，其中该request的HTTP版本号为1.1。

b)Web Server收到request中的HTTP协议为1.1就认为是一个长连接请求，其将在response的header中也增加”Connection： keep-alive“。同是不会关闭已建立的tcp连接。

c)Client收到Web Server的response中包含”Connection： keep-alive“，就认为是一个长连接，不close tcp连接。并用该tcp连接再发送request。（跳转到a)）

3、Patch实现思路

HAProxy client KeepAlive支持的patch主要解决三个问题：

a)Connection: keep-alive“ header处理问题

参见KeepAlive的原理，client KeepAlive对于这个header的处理是在对开启client KeepAlive的frontend上经过的response中增加”Connection: keep-alive“ header；

b)怎么处理重新触发client发过来的request的时机问题

从KeepAlive的原理中可以得知，next request是在完成before request的response被client接收的情况下才发出。因此需要在向client写完before request的response后才能触发。而写完response可以通过计算response中body的长度信息得到（Content-Length或者Chunk信息）

c)怎么触发NOT_FIRST request

在Haproxy中对于对于连接的管理是通过session这个数据结构来实现的。触发NOT_FIRST request就通过重置session这个数据结构来实现。

4、Patch的配置方式

配置方式为在每个Proxy的Front中配置添加：

option cli_keepalive

5、patch代码

附件为基于该版本的Client KeepAlive Patch。

该Patch只支持Client端的KeepAlive。

七. Socket简介

8.1 Socket流程：

Socket是对TCP/IP协议的抽象，是操作系统对外开放的接口

8.2 Socket通信流程

八. 对称加密与非对称加密

1、对称加密与非对称加密算法

（1）对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；

​ 非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

（2）由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

2、算法

（1）非对称加密算法：RSA、DSA（数字签名用）、ECC（移动设备用）、Elgamal、背包算法、Rabin、D-H。

​ **RSA：**由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的；
​ DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）；
​ ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。

（2）对称加密算法： 指加密和解密使用相同密钥的加密算法。对称加密算法用来对敏感数据等信息进行加密，常用的算法包括DES、3DES、AES、DESX、Blowfish、、RC4、RC5、RC6。

DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。
3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。
AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；

3、算法的选择

1. 由于非对称加密算法的运行速度比对称加密算法的速度慢很多，当我们需要加密大量的数据时，建议采用对称加密算法，提高加解密速度。

2. 对称加密算法不能实现签名，因此签名只能非对称算法。

3. 由于对称加密算法的密钥管理是一个复杂的过程，密钥的管理直接决定着他的安全性，因此当数据量很小时，我们可以考虑采用非对称加密算法。

4. 在实际的操作过程中，我们通常采用的方式是：采用非对称加密算法管理对称算法的密钥，然后用对称加密算法加密数据，这样我们就集成了两类加密算法的优点，既实现了加密速度快的优点，又实现了安全方便管理密钥的优点。

那采用多少位的密钥呢？

​ RSA建议采用1024位的数字，ECC建议采用160位，AES采用128为即可。

九. ARP协议

网络层的ARP协议完成了IP地址与物理地址的映射。

​ 首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址：如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址；源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

1、点对点链路使用ARP吗？
答：不使用

2、ARP高效运行的关键是什么？
答：关键是每个主机上都有一个ARP的高速缓存

3、ARP报文的各个字段以及含义？

帧类型：ARP：0x0806 (2)
ARP首部：
硬件类型：硬件地址的类型，1表示以太网地址（2）
协议类型：协议地址的类型，0x0800表示IP地址（2）
硬件地址长度：字节为单位 6（1）
协议地址长度：字节为单位 491
操作类型：2个字节。ARP请求1，ARP回复2，RARP请求3，RARP应答4 （2）
发送者硬件地址：6个字节 （6）
发送者IP地址：4个字节 （4）
目标硬件地址：6个字节（6）
目标IP地址：4个字节（4）
CRC校验：4个字节（4）

**总结：**ARP总共28个字节。记忆方法：以太网先目的后源，ARP先发送端后目的源。先硬件后协议。

问题5：ARP协议有什么弱点？

1. 缓存：主机的地址映射是给予告诉缓存的，动态更新的。地址刷新是有时间限制的。可以通过下次更新之前修改计算机上的地址缓存，造成拒绝服务攻击或者ARP欺骗。
2. 广播：攻击者可以伪装ARP应答。
3. ARP应答没有认证，都是合法的。可以在不接受到请求的时候就发出应答包。

5、ARP代理的概念和应用场景
若ARP请求是从一个网络的主机发送给另一个网络上的主机，那么连接这两个网络的路由器就可以回答该请求，这个过程叫做ARP代理。ARP代理路由器响应ARP请求的MAC地址为路由器的MAC地址而非ARP请求的主机的MAC地址。
ARP代理的应用环境：两个物理网络之间的路由是使用相同的网络号，两个路由器设置成ARP代理，实现相互隐瞒物理网络。

6、免费ARP
指主机发送ARP查找自己到底IP地址，即数据链路层SIP=DIP
作用有两个：

1. 一个主机使用免费ARP确定是有存在有其他主机设置了相同的IP地址
2. 如果发送免费ARP的主机改变了MAC地址，可以通过发送免费ARP的方式告知其他主机端更新ARP表

7、数据链路层MTU的最大值和最小值是多少？

1. 数据链路层的最小MTU为64字节。对于IEEE802.3，两个站点的最远距离不超过2500m，由4个中继器连接而成，其冲突窗口为52.2us（2倍电缆传播延迟加上4个中继器的双向延迟）。对于10Mbps的IEEE802.3来说，这个时间等于发送64字节，即512位的时间，64字节就是由此而来。如果一个站点已经传输了512bit，就认为它已经占用了这个信道。
2. 数据链路层的最大MTU为1500字节，即数据字段的最大长度。

十. IP协议

问题1：如何理解IP的不可靠和无连接。
不可靠：指的是不能保证数据报能成功地到达目的地。
发生错误时候，丢弃该数据包，发送ICMP消息给信源端。可靠性由上层提供。

无连接：IP不维护关于后续数据报的状态信息。
体现在，IP数据可以不按顺序发送和接收。A发送连续的数据报，到达B不一定是连续的，来回路由选择可能不一样，路线也不一样，到达先后顺序也不一样。

问题2：IP报文的格式和各个字段的含义

版本号：IPV4就是4，IPV6就是6（4）
首部长度：4个字节为单位。最小为5，最大为15。所以最小长度20个字节，最大为60个字节。（4）
服务类型：QoS用，目前不怎么使用。（8）
总长度：字节为单位。最多可以传送65535字节的IP数据包。（16）
表示字段（8）
标志（3）
段偏移（5）与分片有关。
生存时间TTL：经过一个路由器减一。字段为0时，数据报被丢弃，并且发送ICMP报文通知源主机。目的是防止数据报在选路是无休止地在网络中流动。（8）
协议：区分上层协议（8）
首部校验和：仅对首部进行校验。（16）【对比：ICMP、IGMP、TCP、UDP：对首部和数据进行校验】
源地址：（32）
目的地址：（32）

问题3：为什么IP首部中要有总长度字段？

因为一些数据链路（以太网）需要填充一些数据以达到最小长度。因为以太网帧的最小长度是46个字节，但是ip长度可能更短，所以需要总长度来确定IP数据部分的内容。

问题4：IP首部校验和怎么计算的？与ICMP、IGMP、TCP、UDP的首部校验和有什么区别和共同点？

1. 先把校验和字段置0。
2. 对首部中每个16位比特进行二进制反码求和。
3. 结构存在校验和字段中。
4. 收到一份IP数据包后，同样对首部中每个16比特二进制反码求和。
5. 最后结果全为1，表示正确，否则表示错误。
6. 如果是错误的，IP就丢弃该数据报，但是不生成差错报文，由上层去处理。

共同点：用到的算法都是一样的。
区别：IP计算的时候没有将数据包括在内。
ICMP、IGMP、TCP、UDP同事覆盖首部和数据校验码。

问题5：主机和路由器本质区别是什么？
主机从不把数据报从一个接口转发到另一个接口，而路由器则要转发数据报。

问题6：IP路由选择的过程是怎么样的？
根据最长匹配原则，找到条目，发送到指定的路由器。如果不能找到，返回一个“主机不可达”或“网络不可达”的错误。

问题7：IP路由选择的特性有什么？

1. IP路由选择是逐跳进行的。
   IP并不知道。到达任何目的的完整路径，只提供下一条地址。
2. 为一个网络指定的路由器。而不是为每个主机指定一个路由器。
   这样可以缩小路由表规模。

问题8：IP搜索路由表的步骤
搜索匹配的主机地址——》搜索匹配的网络地址——》搜索默认选项
IP层进行的选路，实际上是一种选路机制。它搜索路由表并决定向哪个网络接口发送分组。

问题9：如果路由表中没有默认项，而又没有找到匹配项，这时如何处理？
结果取决于该IP数据报是由主机产生的还是被转发的。
如果数据报是由本机产生的，那么就给发送该数据报的应用程序返回一个差错，或者是“主机不可达差错”或者是“网络不可达差错”。
如果是被转发的数据报，就给原始发送了一份ICMP主机不可达的差错报文。

问题10：IP地址的分类是如何划分的，及会计算各类地址支持的主机数。

1. A类地址：首位为0，1.0.0.1~126.255.255.254；主机号24位
2. B类地址：首位为10，128.0.0.1~192.255.255.254；主机号位16位
3. C类地址：首位为110，192.0.0.1~223.255.255.254；主机号8位
4. D类地址：（多播地址，也叫做组播地址）：首位为1110，224.0.0.1~239.255.255.254
5. E类地址：此类地址是保留地址，首位为11110，240.0.0.1~254.255.255.254

十一. ICMP协议

问题1：ICMP的层次和作用

ICMP一般认识是在三层的。主要传递一些差错报文和其他需要注意的信息。

问题2：ICMP报文的分类？

​ ICMP分为两类，一类是ICMP查询报文，另一类是ICMP差错报文。

问题3：ICMP的主机不可达报文是在什么情况下发出的？
三层设备（路由器）给该主机寻路时，没有找到相应路径，向源IP发回ICMP主机不可达。

问题4：什么情况下不会导致产生ICMP差错报文？

1. ICMP差错报文
2. 目的地址是广播地址或者多播地址的IP数据报
3. 链路层广播的数据报
4. 不是IP分片的第一片
5. 源地址不是单个主机的数据包

问题5：ICMP重定向差错报文是怎么来的？在何种场合出现？

1. 主机发送IP数据报给R1，因为主机的默认路由指向的下一跳是R1。
2. R1收到数据报并且检查它的路由表，发现R2是发送该数据报的下一跳。当他将数据报发送给R2的时候，发现发送的接口与接受的端口是一样的，因此同时发送一个ICMP重定向报文给主机。
3. R1接受到ICMP重定向报文后，接下来的数据报就发送给R2，而不再发送给R1。

问题6：重定向报文有什么规则？
重定向报文只能有路由器生成。
重定向报文是为主机而不是为路由器使用的。

十二. XSS 攻击

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

---

1). XSS攻击的危害

• 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
• 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力
• 盗窃企业重要的具有商业价值的资料
• 非法转账
• 强制发送电子邮件
• 网站挂马
• 控制受害者机器向其它网站发起攻击

---

2). 原因解析

主要原因：过于信任客户端提交的数据！

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

进一步分析细节：客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！！！

---

3). XSS 攻击分类

(1). 反射性XSS攻击 (非持久性XSS攻击)

漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)，例如，正常发送消息：

http://www.test.com/message.php?send=Hello,World！1

接收者将会接收信息并显示Hello,World；但是，非正常发送消息：

http://www.test.com/message.php?send=！1

接收者接收消息显示的时候将会弹出警告窗口！

---

(2). 持久性XSS攻击 (留言板场景)

XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。与非持久性XSS攻击相比，持久性XSS攻击危害性更大。从名字就可以了解到，持久性XSS攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

例如，留言板表单中的表单域：
1
1

正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示；而非正常操作流程是攻击者在value填写:

<script>alert(‘foolish!’)；</script> <!--或者html其他标签（破坏样式。。。）、一段攻击型代码-->1

并将数据提交、存储到数据库中；当其他用户取出数据显示的时候，将会执行这些攻击性代码。

---

4). 修复漏洞方针

漏洞产生的根本原因是 太相信用户提交的数据，对用户所提交的数据过滤不足所导致的，因此解决方案也应该从这个方面入手，具体方案包括：

• 将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能
  获取到cookie了（如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击）；

• 表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合。。。。

• 对数据进行Html Encode 处理

• 过滤或移除特殊的Html标签，例如:

十三. 应用层

1、DNS概念，用途，DNS查询的实现算法

概念：

• 域名解析，www.xx.com转换成ip，能够使用户更发辫的访问互联网，而不用去记住能够被机器直接读取的IP地址
• DNS协议运行在UDP协议之上，使用端口号53

主机解析域名的顺序：

• 浏览器的缓存
• 找本机的hosts文件
• 路由缓存
• 找DNS服务器（本地域名、顶级域名、根域名）——>迭代查询、递归查询

2：GET和POST区别

操作方式	数据位置	明文密文	数据安全	长度限制	应用场景
GET	HTTP报头	明文	不安全	长度较小	查询数据
POST	HTTP正文	可明可密	安全	支持较大数据传输	修改数据

3：Cookies和Session的区别

1. Cookies是一种发送到客户浏览器的文本串句柄，并保存在客户机硬盘上，可以用来在某个Web站点会话间持久的保存数据
2. Session其实是指的就是访问者从到达某个特定的主页到离开为止的那段时间。Session其实是利用Cookie进行信息处理的，当用户首先进行了请求后，服务端就在用户浏览器上创建一个Cookie，当这个Session结束时，其实就是意味着这个Cookies就过期了。
3. Cookie数据吧保存在客户端，Session数据保存在服务器端。

4：HTTP2.0和HTTP1的区别

5、ping与telnet的区别

区别：

（1）ping用来检查网络是否通畅或者网络连接速度的命令
（2）telnet是用来探测指定ip是否开放指定端口

题外话

小潘的个人微信公众号【小潘学程序】，有兴趣可给个关注~

一起学习，一起成长