计算机网络

计算机网络概述

---

1. 互联网组成

网络是由若干结点和连接这些结点的链路组成，而互联网是网络的网络，网络与网络之间通过路由器互连，因此总的来说互联网由边缘部分和核心部分组成，其边缘部分由主机组成，为用户提供服务，其核心部分由大量的网络以及连接这些网络的路由器组成，为主机提供连通服务。

2. 计算机网络的性能指标

• 带宽：单位时间内网络中能通过的“最高数据率”，用来表示网络的传输数据的能力
• 吞吐量：单位时间内通过某个网络的实际数据量，这是对现实网络的一种测量。
• 时延：数据从网络的一端传输到另一端所需时间。时延 = 发送时延+传播时延+处理时延+排队时延。
  
  

3. 计算机网络的分层协议

层次	功能	常用协议	数据传输单元
应用层	负责进程间的交互，规定了进程间的交互规则	HTTP,HTTPS,FTP,SMPT,DNS,DHCP	报文
运输层	为不同主机间的进程提供通信服务	TCP,UDP	报文段
网络层	为不同主机间提供通信服务	ICMP，ARP	IP数据报
数据链路层	负责为两个相邻节点提供通信服务	PPP,CSMA/CD	帧
物理层	在各种传输媒体上传输数据比特流		比特

（1） 应用层：应用层定义了进程间的交互规则完成特定网络应用，依赖运输层提供进程间的通信服务。常见的应用层协议有DNS,HTTP,SMPT,FTP等，不同应用层协议其应用进程间通信和交互的规则也不相同"，其中数据传输单元为报文
（2）运输层：运输层为两台主机中进程提供通信服务,依赖网络层提供的主机通信服务，通过多路复用多路分解技术，实现不同进程间的通信，常见运输层协议TCP,UDP，其数据传输单元称为"报文段"
（3）网络层：网络层为不同主机提供通信服务,依赖数据链路层提供的相邻结点的通信服务，两台主机间的数据传输，总是在一段一段的链路上传输的，在两个相邻结点之间数据传送，最终才可实现不同主机间的通信，所以网络层必须依靠数据链路层才可提供不同主机间的通信服务常见网络层协议有ICMP协议，ARP协议等，其中数据传输单元为IP数据报
（4）数据链路层：数据链路层负责为两个相邻结点提供通信服务，常见网络层协议有PPP协议，CSMA/CD协议等其中数据传输单元为帧
（5）物理层：负责在各种传输媒体上传输数据比特流，通过调制解调器实现比特流与信号的相互转化，进而实现比特流的传输，现有的计算机网络的硬件设备和传输媒体种类非常繁多，通信手段也多种多样，物理层尽可能的屏蔽传输媒体和通信手段的差异，使上层的数据链路层感受不到这些差异，其数据传输单元为比特

网络层

---

1. 网络层概述

网络层提供了不同主机间的通信服务，它使异构的网络看上去像一个统一的网络，当不同主机通信时，就好像在单个网络上通信一样，屏蔽了复杂网络中的具体细节。

2. IP地址及其表示方法

2.1 分类ip地址

ip地址被划分为A,B,C,D,E 5类地址，每一个ip地址由网络号和主机号组成，由于这种划分方式不灵活，目前这种传统的分类地址已成为历史，因此只需简单了解即可。

2.2 子网划分

（1） 子网划分基本思路

• 划分子网的方法是从主机号中借用若干位作为子网号，于是两级ip地址在本单元内部变为3级ip地址，在本单元外部仍被看作2级地址。ip ::= {<网络号，子网号，主机号>}
• 划分子网是一个单元内部的事情，本单元以外的网络是看不到这个网络是由多少个子网构成，因为这个单元对外仍表现为一个网络
• 凡是从其他网络发送到本单元某台主机的ip数据报，仍然是根据目的网络号找到连接在本单元网络上的路由器，在本单元的路由器收到ip数据报后，在按子网号找到本单元的子网，最后在子网中找到目的主机。
  

（2）子网掩码：一个普通ip地址无法看出其是否划分子网以及子网号，因而引入子网掩码，子网掩码与ip地址进行与运算即可得出网络地址（网络号+主机号），即可判断网络地址。

（3）使用子网时分组的转发：路由器包括三项内容：目的网络地址，子网掩码，下一跳地址

2.3 超网

超网采用无分类编址，消除了传统的分类的地址的概念，一个网络中可以包含很多子网，子网中仍可包含多个子网，属于一种多层次的划分，不像传统的分类ip编址只有两层，以及子网划分编址只有三层。因而这样可大大减少路由器项目，可充分利用ip地址，使编址以及地址分配更加灵活。

ip ::= { <网络前缀>，<主机号>}，使用CIDR记号，形如a.b.c.d/x，a.b.c.d/x 表示前x位表示ip地址的网络地址，

最长前缀匹配：查找路由表时可能会得到不止一个的匹配结果，所以应当从匹配结果中 选择具有最长前缀匹配的结果。

3. IP地址与MAC地址区别

IP地址是IP层和以上各层使用的地址，是一种逻辑地址，MAC地址是数据链路层及以下使用的地址，是一种硬件地址，与硬件绑定。

4. ARP协议

（1）ARP协议作用

网络层使用的是IP地址，而实际网络的链路上传输数据帧时，必须使用MAC地址，而ARP就是解决同一局域网上IP地址与MAC地址的映射问题。

（2）ARP工作原理

• 每台主机都有一个ARP高速缓存,里面有本局域网的每台主机IP地址与MAC的映射关系，当主机A要想本局域网上的某台主机B发送IP数据报，就先在ARP高速缓存是否存在主机B对应的MAC地址
• 如果没有，则需要想本局域网其他主机广播ARP请求分组，所有运行ARP的主机都会收到该请求分组，若B发现自己的IP地址与ARP请求分组所要查询的IP地址相同，则向A回复ARP响应，告诉A自己的MAC地址，否则不理会。
• A收到ARP响应后，在ARP高速缓存中写入B的IP地址与MAC映射缓存，并且B收到A的ARP请求分组后，也会将A的IP地址与MAC写入ARP高速缓存
• 并且ARP高速缓存中每一个项目都有一个过期时间，以防主机的适配器更换，MAC地址更改的时候，一段时间缓存失效删除后，还是能过通过广播ARP请求分组获得该主机MAC地址
  
  
  

5. ICMP协议

（1）ICMP概述：ICMP允许主机或者路由器提供差错信息和异常信息，ICMP报文是封装在IP数据报中，作为其数据部分，ICMP是一个IP层协议

（2）ICMP分类：ICMP差错报文，询问报文

（3） ICMP常见应用

Ping

Ping 是 ICMP 的一个重要应用，主要用来测试两台主机之间的连通性
Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文，并且它没有通过运输层TCP或者UDP，目的主机收到之后会发送 Echo 回答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

Traceroute

Traceroute 是 ICMP 的另一个应用，用来跟踪一个分组从源点到终点的路径。
Traceroute 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报，并由目的主机发送终点不可达差错报告报文。

• 源主机向目的主机发送一连串的 IP 数据报。第一个数据报 P1 的生存时间 TTL 设置为 1，当 P1 到达路径上的第一个路由器 R1 时，R1 收下它并把 TTL 减 1，此时 TTL 等于 0，R1 就把 P1 丢弃，并向源主机发送一个 ICMP 时间超过差错报告报文；
• 源主机接着发送第二个数据报 P2，并把 TTL 设置为 2。P2 先到达 R1，R1 收下后把 TTL 减 1 再转发给 R2，R2 收下后也把 TTL 减 1，由于此时 TTL 等于 0，R2 就丢弃 P2，并向源主机发送一个 ICMP 时间超过差错报文。
• 不断执行这样的步骤，直到最后一个数据报刚刚到达目的主机，主机不转发数据报，也不把 TTL 值减 1。但是因为数据报封装的是无法交付的 UDP，因此目的主机要向源主机发送 ICMP 终点不可达差错报告报文。
• 之后源主机知道了到达目的主机所经过的路由器 IP 地址以及到达每个路由器的往返时间。
  
  
  
  

6. 网络地址转换 NAT

（1） NAT原理：NAT是一种将本地ip地址转化为公网地址，使其能够访问外网对一种技术，它维护着一个NAT转换表，保存着本地ip+端口与公网ip+端口映射关系。当本地主机请求外网时，NAT路由器会根据NAT转换表将其本地ip地址+端口转换成外网ip+端口发出访问请求，当收到回复时，又会根据NAT转换表将回复转发给指定对本地主机

（2） NAT作用

• 完美地解决了lP地址不足的问题
• NAT不仅实现地址转换，同时还起到防火墙的作用，隐藏内部网络的拓扑结构，有效地避免来自网络外部的攻击,因为对于外部主机来说，内部主机是不可见的,NAT 之内的 PC 联机到 Internet 上面时，他所显示的 IP 是 NAT 主机的公共 IP。
  
  
  

运输层

---

1. 运输层概述

网络层提供不同主机间的通信服务，而真正通信的实体是在主机里的进程，网络层虽然能把分组送至目的主机，但这个分组还仍在这个主机，没有交付至具体的应用进程。而运输层实现了应用进程间的逻辑通信，好像就是两个应用进程延水平方向直接传输数据。运输层通过复用收集所有应用层的报文并负责寄出，通过分用将从IP层收到的数据报分发给指定的应用进程

2. UDP协议

2.1 UDP主要特性

• 无连接：UDP发送数据前无需建立连接，无需和对方打招呼就可直接发送数据，并且收到数据也无需回复，这种特点决定了UDP的简单高效
• 不可靠交付：UDP不保证数据的可靠交付，若需要保证数据的可靠性需要使用TCP
• 无拥塞控制：UDP无拥塞控制机制，网络拥塞不会使源主机的发送速率降低，许多实时应用（如实时视频通话，IP电话）对源主机的速率有要求，允许在网络拥塞时丢弃一些数据，但却不允许太长的时延，而UDP适合这类对时延，发送速率有要求，允许数据的丢失的应用
• 支持一对一，一对多，多对多的交互通信
• UDP面向报文：UDP对应用层交付的报文，既不合并也不拆分，加个UDP首部直接向IP层进行交付，从IP层获取的数据报，去除首部后直接交付给应用进程。

2.2 UDP报文 = 8字节UDP首部+应用层数据报

• 源端口：需要给对方回信时使用
• 目的端口：交付给指定进程时使用，目的端口不存在，则丢弃报文并发送ICMP目的端口不可达报文
• 长度：UDP首部+数据 长度
• 校验和：用于检验首部+数据，出错则丢弃。
  

3. TCP协议

3.1 TCP主要特性

• 面向连接：TCP是面向连接的，发送数据前必须建立TCP连接
• 提供可靠交付：TCP提供可靠交付，保证了传输的数据无差错，不丢失，不重复，按序到达。也就是你发送什么，我就能接收到什么
• 流量控制：接收方可根据自己的接受数据的能力，对发送方的流量进行控制。
• 拥塞控制：在网络拥塞情况下，可限制发送方的发送速率。它根据网络的拥塞情况，动态调整发送方的发送窗口大小即发送速率
• 只支持点对点通信：使用TCP连接只能进行点对点通信，不能进行一对多，多对多通信
• TCP面向字节流：TCP缓存应用层传输的字节，其发送的报文长度会根据自己的窗口调整，并且可以等待有足够多的字节才过构成报文发出去

3.2 TCP报文：TCP报文 = 20字节固定首部 + 应用层数据报

• 源端口和目的端口：源端口和目的端口各占2字节，与UDP中端口作用一样
• 序号：4字节，TCP是面向字节流的，每一个字节有一个对应的编号，而序号记录的是本报文段所发送数据的第一个字节编号，比如一报文段第一个字节序号为301，携带100字节数据。显然下一个报文段的序号应从401开始。
• 确认号：4字节，是期望下一次收到的报文段序号，比如确认号为N,则表明到序号为N-1的字节已全部接受，期望下次发送序号为N的报文
• 数据偏移：记录TCP首部长度，因为TCP首部存在可选字段，长度可变，所以需要记录
• ACK：当ACK=1时，确认号才有效，ACK=0时，确认号无效，并且连接建立后所有报文段ACK都为1
• SYN: SYN用于在连接建立时进行同步序号，SYN=1，ACK=0,表明这是一个连接请求报文，SYN=1,ACK=1表明这是一个连接接受报文。
• FIN：FYN用于在释放连接，FIN=1,表明数据已发送完毕请求断开连接
• 窗口：窗口值用于接收方让发送方调节窗口大小，一般进行流量控制和拥塞控制会用到
• 检验和：用于检验TCP首部+数据，错误则丢弃
  

4. 端口与套接字区别

• 端口：端口唯一标识本地主机的进程，每个进程都有一个端口与之对应，但端口号只具有本地意义，16位的端口号可允许65535个不同端口

  • 熟知端口号：0-1023，将这些端口号给重要的应用程序，让所有用户都知道
  • 登记端口号：1024-49151，这类端口号为没有熟知的应用程序使用
  • 短暂端口号：49162-65535，这类端口号给客户端进程暂时使用，客户端进程会在运行时动态选择其中一个未使用的端口号
    

• 套接字：套接字socket = <ip地址,port端口号>，唯一标识不同主机的应用进程
  
  
  

5. 可靠传输

5.1 滑动窗口协议

发送方：发送方维护着一个发送窗口（窗口中表示可发送的字节，一部分已发送但未确认，一部分允许发送但未发送，窗口左边表示已发送并且已确认的），当收到确认后窗口向前滑动。直到遇到有数据超时未确认时，回退N步重传。

接收方：接收方采用累计确认，接收方不必对收到的每个分组进行确认，而是在收到几个分组后，对按序到达的最后一个分组进行确认，再将自己的接收窗口向前滑动

6. 流量控制

6.1 原理

一般来说，我们总是希望数据传输的很快，但是可能会存在发送方发送数据过快，导致接收方来不及接受，会导致数据丢失，而流量控制会根据接收方的rwnd窗口，调整发送方的发送窗口，进而达到对发送方进行流量控制。假设A向B发送数据。在连接建立时，B告诉A:“我的接受窗口rwnd=400”，你的发送窗口不能超过这个数值哦。

6.2 流量控制中的死锁

假设以下图为例，B向A发送rwnd=0报文后,表示A接收到零窗口通知，将不会发送数据给B,过了一会B缓存又有了一些空间，因此B向A发送rwnd=400报文段，但这个报文可能丢失，这是双方就会陷入死锁状态，谁也不理谁，都会认为对方无数据可发*。因此TCP为解决这个问题为每一个TCP连接设一个持续计时器，只要收到对方的零窗口通知，就启动计时器，若计时器到期时仍未收到对方的窗口值，就发送一个零窗口探测报文去询问下，而对方收到之后就会给出当前窗口值，如果窗口仍是0，则重设计时器继续上述过程，否则死锁被打破

7. 拥塞控制

• 慢启动：当主机开始发送数据时，并不清楚网络的负载情况，如果立即把大量的字节注入网络中，可能会加重网络拥塞，因此较好的方法是先探测一下，由小至大的增大拥塞窗口，从cwnd=1开始，每接收到一个报文段的确定，其拥塞窗口cwnd+1，因此每传输一轮，拥塞窗口cwnd会增倍。直至到慢启动门限sstresh，开始拥塞避免。
• 拥塞避免：拥塞避免让拥塞窗口cwnd缓慢增大，线性增长，每传输一轮，拥塞窗口cwnd+1,以此让网络不容易出现拥塞，直到出现超时时间或者3-ACK事件
• 超时：若出现ACK确认超时事件，而超时事件一般是网络拥塞的标识，这时候会直接将拥塞窗口cwnd=1,开始慢启动，避免进一步加剧网络拥塞
• 快重传：快重传为尽早知道发生了个别报文的丢失，接收方如果收到不是自己想要的报文，会立即进行重复确认，比如接收方收到了M1，M2报文给与确认，发送方继续发送M3,M4报文，但是M3报文丢失，接受方收到了M4，因此确认M2,说我想要M2的下一个报文M3,发送方接着发送M5，M6，接收方还是确认M2,说我想要M2的下一个报文M3，发送方一旦连续的三个重复对M2的ACK确认，就会确认M3丢失，立即重传M3，并将拥塞窗口cwnd减半.
• 快恢复：将拥塞窗口cwnd减半，并且执行拥塞避免算法。
  
  
  

8. TCP三次握手/四次挥手

8.1 TCP三次握手

(1) 客户端发起TCP连接请求，置SYN=1，ACK=0，选择一个初始序号seq=x
(2) 服务器收到TCP连接报文后，对该连接请求进行应答，置SYN=1,ACK=1,ack=x+1，选择一个初始序号seq=y
(3) 客户端收到TCP连接应答后，对该应答进行确认，置ACK=1,seq=x+1,ack=y+1.服务器收到该去确认报文后，分配TCP缓存，连接建立成功，可进行数据传输

为什么TCP需要第三次握手？

• TCP三次握手避免了无效连接，考虑这样一种情况，若客户端发起的第一个连接请求在网络中阻塞了，客户端长时间未收到服务器对该连接的应答，因而产生超时事件会再次发起连接请求，假设这次请求顺利完成，TCP连接建立成功，但若第一个连接请求随后也被服务器接受到，因而服务器会发出连接应答，若此时只有二次握手则会再次建立TCP连接,浪费服务器资源。若三次握手，则客户端收到服务器的应答后不予理睬，因为它知道这是一次无效连接。
• TCP三次握手 + SYN Cookie，区分了SYN洪泛攻击和正常的SYN连接请求，避免了服务器为SYN洪泛攻击创建半开连接耗尽资源的情况，若有人发起SYN洪泛攻击，服务器在接收到SYN 连接请求后，会生成初始序号y，该序列号是经过根据源和目的ip地址，端口号，并经过秘密的散列函数生成的，这个序列号就叫做SYN Cookie，服务器发送带有这种特殊序列号的应答报文，如果客户端是合法的，它将会返回一个序列号为y+1对应的ACK报文，服务器会根据源和目的IP地址，端口号，以及秘密的散列函数验证这个ACK报文中的序列号是否符合要求，若验证成功则知道该连接是正常的SYN请求，最后才进行同意建立连接，资源分配。

8.2 TCP四次挥手

（1）客户端发送完数据后，想要结束TCP连接，因此发送连接释放请求，FIN=1,ACK=0,seq=u,为客户端最后一个传输的字节序号+1
（2）服务器收到连接释放请求后，对其进行确认，发起确认报文，ACK=1，ack=u+1,seq=v（等于服务器传送的最后一个字节序号+1），此时TCP处于半关闭状态
（3）若此时服务器仍有数据要传输，则先进行传输，传输完毕后再发送连接释放请求，FIN=1，ACK=1，ack=u+1，seq=w（等于服务器传送的最后一个字节序号+1，服务器中间又传输了一些数据)，
（4) 客户端收到连接释放请求后，对其进行确认，发起确认报文，ACK=1,ack=w+1,seq=u+1,然后进入等待一段时间再关闭连接，服务器收到确认后，则可关闭连接。

如何保证服务器的连接在异常情况下一定能关闭？

• 时间等待计时器：假设客户端发送给服务器的连接释放确认报文丢失，若客户端不等待一段时间而直接关闭连接，会导致服务器再次发出连接释放报文无人回应，服务器无法释放连接。而客户端等待一段时间在释放连接，若确认报文丢失，则服务器过一段时间会再次发出连接释放请求，而客户端还未释放连接，仍可对其进行确认。

• 保活计时器：假设客户端出了问题，无法发出报文，因此此时服务器根本无法关闭连接，因而服务器启动一个保活计时器，服务器每收到一次客户端数据，则将保活计时器重置，若两小时没有收到客户端报文，则发送探测报文，以后每隔75s发送一次探测报文，若连续10个探测报文都没有回复，则服务器认为客户端出现故障，直接关闭连接

应用层

---

1. DNS

1.1 DNS概述

DNS是一个域名解析协议，负责将域名解析为对应的ip，DNS由一个分层次分布式数据库组成，为整个互联网提供了高可用可扩展的域名解析服务，并且DNS协议运行在UDP之上，使用53端口

1.2 DNS工作原理

DNS采用大量的服务器，以层次化的方式组织，由根DNS服务器，顶级DNS服务器，权威DNS服务器组成，并且存在一个本地DNS服务器，本地DNS服务器有一个高速缓存记录域名与ip地址映射关系，因此一次DNS请求，先去查找本地DNS服务器，若命中缓存则直接返回，否则由本地域名服务器先向根服务器查询，根服务器告诉本地服务器下一次查询的顶级域名服务器的地址，本地服务器向顶级域名服务器查询，顶级域名服务器告诉本地服务器下一次查询的权威域名服务器，本地服务器再向权威域名服务器查询，找到对应的ip地址，并进行缓存。

2. HTTP

2.1 HTTP概述

HTTP协议是超文本传输协议，在浏览器与服务器之间进行请求响应的交互，并且遵循HTTP协议的格式和规定，HTTP使用运输层TCP协议实现数据的可靠传输。

2.2 HTTP请求方法

• GET：从指定的资源获取数据
• POST：向指定的资源提交数据
• HEAD：只获取响应报文首部，不获取响应报文内容，常用于确定URI有效性
• PUT：上传文件
• DELETE：删除文件
• OPTIONS：询问服务器支持的方法

比较 GET 与 POST

• GET与POST是HTTP请求的两种方式，都是基于TCP传输，无本质区别，主要是在常规的用法上有较大区别，GET请求用于获取数据，而Post请求用于提交数据
• GET请求参数一般放在URL后，一般浏览器或者服务器对url会有长度限制，POST请求参数一般放在请求主体中，无长度限制
• 由于HTTP本身是不安全的，GET和POST也都是不安全的，若需要安全传输只有通过HTTPS，但POST相对于GET安全一点，因为所发送的数据是 URL 的一部分，在发送密码或其他敏感信息时绝不要使用 GET ！
• GET会将请求数据缓存，参数会保存在在浏览器历史，而POST不能缓存，参数也不会被保存

2.3 HTTP状态码

HTTP状态码的责任是当客户端向服务器发出请求时，返回请求的结果，借助状态码，用户可以知道服务器是正常处理了请求还是出现了错误

• 1XX：表请求已被接受，但仍在处理，一种临时响应
  • 100 Continue：服务器仅接收到部分请求，但是服务器并没有拒绝该请求，客户端应该继续发送其余的请求。
• 2XX:表请求被正常处理
  • 200 OK: 请求处理成功
  • 204 Not Content：请求处理成功，但无资源返回，在响应报文中无内容实体，一般在只需要客户端往服务器发送信息，而对客户端不需要发送新内容的情况下使用
  • 206 Partial Content：请求处理成功，并且客户端进行的是范围请求，而服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的这部分内容
• 3XX：表示重定向
  • 301 Moved Permanently: 永久重定向，告知客户端请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
  • 302 Found: 临时重定向，自动将请求者转到新位置。但请求者应继续使用原有位置来进行以后的请求。
  • 303 See Other：临时重定向，与302 Found有相同含义，但希望客户端采用GET进行重定向。
  • 304 Not Modified：自从上次请求后，请求的网页未修改过，服务器返回此响应时，不会返回网页内容，浏览器可使用缓存
  • 307 Temporary Redirect：临时重定向，与302 Found有相同含义，但是307遵循浏览器标准，不会将Post变为Get，而301，302基本上不会遵循标准，一般会将Post变为Get进行重定向请求
• 4XX：表客户端请求错误
  • 400 Bad Request：请求出现错误，如缺少参数或者错误的请求参数
  • 401 Unauthorized：请求之前需要进行身份认证
  • 403 Forbidden：资源无权访问
  • 404 Not Found：服务器无法找到请求资源或者服务器拒绝服务并不想给出理由
• 5XX：表服务器错误
  • 500 Internal Server Error : 服务器内部错误，可能是服务器bug或者临时故障
  • 503 Service Unavailable：服务器目前无法使用，无法处理请求

2.4 HTTP1.0，HTTP1.1，HTTP2.0

（1）HTTP1.0
早先1.0的HTTP版本，是一种无状态、无连接的应用层协议。

• 无状态：HTTP协议是一种无状态协议，服务器不跟踪每个客户端也不记录过去的请求（无状态），但可通过Session/Cookie解决
• 非持久连接：HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接。

无连接的特性导致最大的性能缺陷就是无法复用连接。每次发送请求的时候，都需要进行一次TCP的连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率非常低。

其次就是队头阻塞。由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。

为了解决这些问题，HTTP1.1出现了。

（2）HTTP 1.1
对于HTTP1.1，不仅继承了HTTP1.0简单的特点，还克服了诸多HTTP1.0性能上的问题。

• 持久连接：HTTP1.1增加了一个Connection字段，通过设置Keep-Alive可以保持HTTP连接不断开，避免了每次客户端与服务器请求都要重复建立释放建立TCP连接，提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection: false来告知服务器关闭请求。
• 流水线：HTTP1.1可以连续发送多个请求，而不用像HTTP1.0一样必须等到前一个请求响应才能发送下一个请求，但服务器响应仍是串行化响应，不允许同时存在两个并行的响应。虽然HTTP1.1支持管道化，但实际效果很差，服务器必须逐个返回响应，这个是很大的一个缺陷。实际上，现阶段的浏览器厂商采取了另外一种做法，它允许我们打开多个TCP的会话。利用多个TCP连接实现HTTP请求和响应的并行。
• 支持断点传输：在HTTP1.0中存在带宽的浪费，不能只请求对象的一部分，请求整个对象，而HTTP1.1在请求头引入了range头域允许只请求资源的某个部分，返回状态码206（Partial Content），因而支持断点传输
• 更多的缓存控制策略：HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准 而HTTP1.1则引入了更多的缓存控制策略如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

（3）HTTP 2.0

• 数据格式：http2.0采用的是二进制格式，http1.1采用的是文本格式。 二进制协议解析起来更高效，更紧凑，错误更少。
• 多路复用：同一个连接可以并发处理多个请求，同时处理多个消息的请求和响应，而且并发请求的数量比HTTP1.1大了好几个数量级
• 消息头压缩：HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
• 服务器推送：服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求, 免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。服务器端推送的这些静态资源下发到本地客户端，客户端直接从本地加载这些资源，页面加载速度会大大提高。

2.5 HTTPS

2.5.1 HTTPS简介

HTTPS是HTTP的安全版，是使用 TLS/SSL 加密的 HTTP 协议，为http数据传输提供了身份认证，数据的保密性与完整性保证。

2.5.2 HTTPS加密原理

https加密原理：证书(用户验证服务器身份的过程)+数字签名（服务器验证用户身份的过程）+非对称密钥（用于第一次Http连接时确定双方对称密钥）+对称密钥（之后的通信都用对称密钥，用于数据加密）

1. 客户端请求服务器证书以及发送其支持的加密算法列表

2. 服务器接收请求，返回服务器生成的数字证书和选择的加密算法，

3. 客户端接收服务器传回的证书和加密算法，此时，客户端首先校验证书的合法性，如果此时校验失败，客户端会立刻发出警告，由用户决定是否继续，如果校验成功，此时客户端则会针对服务器传回的加密算法，生成一个随机的密钥，并对其进行数字签名，并用公钥加密之后，发送给服务端

4. 服务端接收到客户端传回的随机密钥之后，用持有的私钥进行解密，对签名进行检验，检验成功后取得客户端发送的随机密钥，此时服务端会使用当前密钥，对数据进行对称加密之后传给客户端

5. 客户端取得加密数据之后，用上一个回合生成的密钥解开密文，取得响应数据

6. 客户端和服务端会持续使用约定的密钥对数据进行加密交互

2.5.3 HTTP 与 HTTPS 区别

1. HTTP 明文传输，数据都是未加密的，存在信息窃听、信息篡改和身份伪造的风险，而HTTPS 具有身份验证、信息加密和完整性校验的功能，可以避免此类问题。
2. 使用 HTTPS 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用，更加消耗服务器资源，并且速度比HTTP慢，在安全性不那么重要的场合应使用HTTP

3. DHCP

3.1 DHCP概述

DHCP是一种动态主机配置协议，它允许一台计算机自动配置IP地址，DNS地址等信息，提供即插即用入网功能。对于经常移动位置的计算机十分方便，无需手工配置即可入网。

3.2 DHCP原理

（1）DHCP服务器发现：一台新到的主机首要任务就是发现一个要与其交互的DHCP服务器，DHCP客户端广播DHCPDISCOVER发现报文，本地主机都能收到该发现报文，但只有DHCP服务器会会对其响应，若本地无DHCP服务器，则通过DHCP中继代理（通常为路由器，它知道DHCP服务器ip地址），转发至指定的DHCP服务器，
（2）DHCP服务器提供：DHCP收到该发现报文后，DHCP服务器会先去数据库中查看该计算机的配置信息，若找到则返回，若没有找到则在ip池取一个地址分配给该计算机，其中包含了ip地址，子网掩码，租用期等配置信息。
（3）DHCP请求：凡是收到DHCP发现报文的DHCP服务器都会响应一个DHCP提供报文，客户端可能会收到多个DHCP提供报文，因此客户端会在其中选择一个，并向其选择的DHCP服务器发送DHCP请求报文，回显配置参数
（4）DHCP确认：服务器用DHCP ACK对DHCP请求报文进行确认，证实所要求参数
（5）更新租用期：主机只能临时使用该ip地址，因此具有一个租用期，主机会启动计时器，当租用期快到了就会请求更新租用期，对该DHCP服务器再次发出DHCP请求，请求更新租用期。

网络安全

1. 网络安全三要素

信息安全中有三个需要解决的问题：

• 保密性(Confidentiality)：信息在传输时不被泄露，明文不能被窥探
• 完整性（Integrity）：信息在传输时不被篡改，篡改后能被发现
• 有效性（Availability）：信息的使用者是合法的，能鉴别双方身份
  
  

2. 保证网络安全的几种方式

2.1 对称加密

对称加密原理：由通信双方共同确定一套密钥用于加密解密

优点：对称加密使用起来简单快捷，密钥较短，破译困难,适合大数据量的加密工作

问题： 对称密钥的管理和分发工作是一件具有潜在危险的和烦琐的过程，密钥一旦被攻击者获取，则加密无效

2.2 非对称加密

非对称加密原理：公钥加密，私钥解密，公钥公开对外，私钥保密。甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。

优点：相对于非对称加密安全

缺点：处理速度慢，并且服务器发送给客户端公钥时，被攻击者截断则攻击者可伪造公钥，利用自己私钥获取密文，可通过下面谈到的证书解决这个问题

2.3 散列函数

用于报文完整性鉴别原理 ：A将消息进行散列得到哈希值加到消息后，一并发过去，B收到消息对消息进行散列与消息后的哈希值进行对比，若相等则说明报文未被篡改，若不等，则说明报文被篡改

用于密码密文存储验证原理：将密码进行散列得到哈希值存储在数据库中，当用户进行账号密码验证时，根据用户名找到用户，根据发送密码，将密码散列后得到的哈希值与数据库中的哈希值对比，若相等则验证成功。这样可防止数据库泄漏后用户密码泄漏，但若一个用户密码与其他用户密码相同，则他们数据库的哈希值相同，那么该用户如果能看到数据库的用户信息，就可以盗取与自己相同密码的用户信息，可以采用加salt方法（可通过UUID生成），保证即使相同密码也得到不同哈希值。

常见的散列函数：MD5，SHA。

2.4 数字签名

数字签名使用散列函数+私钥加密，公钥解密，一般用于对用户身份鉴别，解决有效性问题

数字签名原理

• 生成签名：对消息进行哈希计算，得到哈希值利用私钥对哈希值进行加密，生成签名将签名附加在消息后面，一起发送过去

• 验证签名 收到消息后，提取消息中的签名用公钥对签名进行解密，得到哈希值1。若解密成功则成功验证用户身份，对消息中的正文进行哈希计算，得到哈希值2，此时验证数据完整性，比较哈希值1和哈希值2。如果相同，则数据未被篡改。
  
  

2.5 证书

什么是Https证书：Https证书实质上是一种身份认证，通过向CA机构申请证书，即可完成身份认证，标识自己身份，防止其他人伪造自己身份。部署了HTTPS证书的Web服务器就能对外提供安全可靠的HTTPS服务

证书解决的问题：使用非对称加密时，服务器发送给客户端公钥时，若被中间人拦截发送伪造公钥时，如何处理？ 必须使用证书进行身份验证，验证接受的公钥确实是服务器发送的。

Https证书产生过程 ：
（1）服务器进行证书申请，服务器先要产生用与加解密的公私钥对，然后服务器将公钥以及个人身份信息（域名）一起发送给CA机构
（2）CA进行信息审核，对申请者进行验证，验证企业是否合法，是否拥有域名所有权等等，
（3）签发证书，CA机构对证书进行数字签名，然后发出HTTPS证书。
（4）用户从CA机构中得到HTTPS证书后，把HTTPS证书以及自己的私钥部署的web服务器中，这样Web服务器就能够对外提供HTTPS服务了

Https证书验证过程：
（1）验证证书的合法性，当用户采用HTTPS协议访问你的网站时，首先会从你的服务器中得到HTTPS证书，客户端会内置CA公钥，进行证书数字签名验证，确定证书确实是CA机构颁发并且未被篡改
（2）验证证书相关域名信息，有效信息等，验证证书的域名是否是当前服务器的域名，确定证书确实是这个服务器网站的
（3）从证书中得到公钥，用户即可向Web服务器传输数据时，使用了证书中的公钥对传输数据进行加密，然后把密文发送给Web服务器。Web服务器得到密文后，再使用私钥对密文进行解密，最终得到用户的原文信息。

关于中间人攻击与https证书
即便有人截取服务器A证书，若对证书进行篡改，由于CA机构对证书进行了数字签名会被客户端发现，若使用自己的证书，发给客户端，冒充服务器A，也无法实现。因为证书和url的域名是绑定的，客户端也会发现。

3. 几种常见的Web攻击手段及其预防方式

• XSS(跨站脚本攻击)
• CSRF(跨站请求伪造)
• SQL注入
• DDOS(分布式拒绝服务攻击)

3.1 XSS

攻击者在网页中嵌入恶意Script脚本，将输入数据变成Script脚本执行。

案例：比如说我写了一个博客网站，然后攻击者在上面发布了一个文章，内容是这样的 ,如果我没有对他的内容进行处理，直接存储到数据库，那么下一次当其他用户访问他的这篇文章的时候，服务器从数据库读取后然后响应给客户端，浏览器执行了这段脚本，然后就把该用户的cookie发送到攻击者的服务器了。

预防： 对输入数据特殊字符进行转译处理，比如将<转义为&lt ;

3.2 SQL注入

攻击者伪造参数，进行sql参数拼接形成危害性sql语句

案例： or ‘1’= ‘1’。这是最常见的sql注入攻击，当我们输如用户名 jiajun ，然后密码输如’or ‘1’= ‘1的时候，我们在查询用户名和密码是否正确的时候，本来要执行的是select * from user where username=’’ and password=’’,经过参数拼接后，会执行sql语句 select * from user where username=‘jaijun’ and password=’ ’ or ’ 1’='1 '，这个时候1=1是成立，自然就跳过验证了。

预防：使用预编译语句（PreparedStatement），避免sql语句拼接

3.3 CSRF

攻击者利用用户的cookie进行认证，然后伪造用户发出请求

案例：受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。

黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。

这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。

预防：
（1）验证 HTTP Referer 字段：
在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL
（2）在请求地址中添加 token 并验证：
生成随机token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上 ，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

3.4 DDOS

攻击者借助公共网络，向一个目标发出大量请求导致服务器带宽不足，无法对外提供服务

案例：CC攻击，在应用层http协议上发起攻击，模拟正常用户发送大量请求直到该网站拒绝服务为止。

预防：
* 最直接的方法增加带宽
* 建立攻击防御点，过滤攻击流量，将正常流量转发至源站