《计算机网络》之——计算机网络-知识点整理
《计算机网络面经》网络整理而来
TCP相关
TCP的整个流程（状态转换过程）
要求：不是简单的描述，而是将整个状态转换过程描述清楚…
服务器端的典型状态转移：
客户端的典型状态转移：
TCP状态转移总图：（粗实线：客户端典型状态转移，粗虚线：服务端典型状态转移，细实线：非典型状态转移）
TCP三次握手过程
三次握手(我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功)：
- 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
- 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
- 第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，
完成三次握手，随后Client与Server之间可以开始传输数据了。
TCP四次挥手过程
四次挥手(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)：
- 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
- 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态，Client收到ACK后进入FIN_WAIT_2状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
- 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
- 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
为什么TCP需要三次握手？
-
为什么两次不可以：
防止服务器端因接收了早已失效的连接请求报文，从而开启连接，一直等待客户端发送数据，最终导致形成死锁、浪费资源
比如：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段，但是server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求，于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了，由于client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据，但server却以为新的运输连接已经建立，并一直等待client发来数据。所以没有采用“三次握手”，这种情况下server的很多资源就白白浪费掉了。 -
为什么不是四次：
可以但没必要，第二、三次可以合并的，四次浪费资源
为什么TCP需要四次挥手？
-
为什么握手只需要三次，而挥手需要四次呢
因为3次握手可以直接发SYN+ACK，确认报文段跟同步报文段是合一起发的，所以有3次，
挥手时服务器收到FIN时，可能还要数据要发，不能立即关闭连接，所以要先发ACK报文段，如果有数据的话要把数据都传完再发FIN。故连接释放报文段跟确认报文段分开发，所以有4次 -
不能等待服务端传送完数据直接发送ACK+FIN么？这样只需要三次
因为这样客户机没有等到确认，会以为是超时，会进行超时重传
为什么要有TIME_WAIT状态？为什么等待2MSL？
TIME_WAIT状态等待2MSL
MSL是报文最大生存时间；
主动方发出最后一个ACK包进入TIME_WAIT状态，目的是防止最后一个ACK包对方没接收到：对方在超时后将重发第三次挥手的FIN包。 主动关闭方向被动关闭方发送最后一个ACK：等待ACK到达对方时间MSL+等待FIN超时重传MSL，所以如果2MSL时间没有收到FIN，说明对方安全收到ACK。
如果主动关闭方在TIME_WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，若最后一个ACK丢失，则无法收到被动关闭方重传的FIN报文段，因而也不会再发送一次确认报文段。这样，被动关闭方就无法按照正常的步骤进入CLOSED状态。
如果客户端第三次握手失败了，第三次ack信号没有到达服务端会发生什么情况
当客户端收到服务端的SYN+ACK应答后，其状态变为ESTABLISHED，并会发送ACK包给服务端，准备发送数据了。
如果此时第三次的ACK在网络中丢失，过了超时计时器后，那么Server端会重新发送SYN+ACK包（重传次数根据/proc/sys/net/ipv4/tcp_synack_retries来指定，默认是5次）。如果重传指定次数到了后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，Client方能感知到Server的错误，则会关闭这个连接。
三次握手、四次挥手中可能出现的意外情况，会发生什么，参考这篇博客。
TCP、UDP的区别，应用场景，协议举例
- 区别及应用场景：
总结来说：
TCP：面向连接，可靠传输，字节流服务
UDP：面向无连接，不可靠传输，数据报服务
TCP：只支持点对点通信
UDP：支持一对一、一对多、多对一、多对多的通信模式
TCP：速度慢。首部开销20个字节
UDP：速度快（不需要连接等待、少了许多操作）。首部开销8个字节
TCP：发送消息之类的场景，因为你要确保用户的消息不会丢失，需要使用TCP协议
UDP：进行视频聊天或者看直播，那可以使用UDP协议，因为即使几个画面丢失了，对用户来说影响也不是很大。
- 区别及应用场景： 答案2
UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等。
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的运输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
- TCP对应的协议和UDP对应的协议
TCP对应的协议：
（1） FTP：定义了文件传输协议，使用21端口。
（2） Telnet：一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
（3） SMTP：邮件传送协议，用于发送邮件。服务器开放的是25号端口。
（4） POP3：它是和SMTP对应，POP3用于接收邮件。POP3协议所用的是110端口。
（5）HTTP：是从Web服务器传输超文本到本地浏览器的传送协议。
UDP对应的协议：
（1） DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
（2） SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
（3） TFTP(Trival File Transfer Protocal)，简单文件传输协议，该协议在熟知端口69上使用UDP服务。
为什么 TCP 叫字节流模式？ UDP 叫数据报模式？
所谓的“字节流模式”，是指TCP发送端发送几次数据和接收端接收几次数据是没有必然联系的，比如你通过 TCP连接给另一端发送数据，你只调用了一次 write，发送了100个字节，但是对方可以分10次收完，每次10个字节；你也可以调用10次write，每次10个字节，但是对方可以一次就收完。
原因：这是因为TCP是面向连接的，一个 socket 中收到的数据都是由同一台主机发出，且有序地到达，所以每次读取多少数据都可以。
所谓的“数据报模式”，是指UDP发送端调用了几次 write，接收端必须用相同次数的 read 读完。UDP是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。
原因：这是因为UDP是无连接的，只要知道接收端的 IP 和端口，任何主机都可以向接收端发送数据。 这时候，如果一次能读取超过一个报文的数据， 则会乱套。
TCP协议如何来保证传输的可靠性
TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。
对于可靠性，TCP通过以下方式进行保证：
- （将数据截断为合理的长度）：应用数据被分割成TCP认为最适合发送的数据块。TCP 给发送的每个报文段进行编号（报文段的序号）
- （对失序数据进行重新排序）：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
- （超时重传）：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
- （校验和）：TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。TCP发送数据端超时时会重发数据。
- （数据确认）：当TCP收到发自TCP连接另一端的数据，它将发送一个确认
- （丢弃重复数据）：(对于重复数据，能够丢弃重复数据
- （流量控制）：TCP可以进行流量控制，防止较快主机致使较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议。
- （拥塞控制）：当网络拥塞时，减少数据的发送。通过慢启动、拥塞避免、快速重传、快速恢复。
TCP的流量控制
TCP 利用滑动窗口实现流量控制的机制。滑动窗口（接收窗口rwnd）的大小意味着接收方还有多大的缓冲区可以用于接收数据。
通过接收端发送带有接收窗口大小rwnd的ACK来实现流量控制。
持续计时器：当收到零窗口通知，就启动持续计时器，超时则发送零窗口探测报文段，避免发送端一直接收不到非零窗口的通知而处于死锁的局面（接收端的非零窗口ACK丢了，发送端也无法发送数据报，则接收端也无法再次回复ACK）
TCP的拥塞控制
拥塞控制就是：防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。判断网络拥塞的依据就是出现了超时。
拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口等于拥塞窗口。
拥塞控制的方法主要有以下四种：（参考《计算机网络第七版谢希仁P232》）
1). 慢开始：慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。直到达到慢开始门限ssthresh。
2). 拥塞避免：达到慢开始门限后，拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。如果发生了拥塞，就减半慢开始门限ssthresh，并从头执行慢开始算法。
3). 快重传：首先接收方要立即发送确认，而不要等到数据接收方自己发送数据时捎带确认。其次，接收方在收到一个 失序的报文段 后也要立即发出 重复确认（因为是累积确认），为的是使发送方及早知道有报文段没有到达对方。快重传算法规定，发送方只要一连收到3个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器超时。
4). 快恢复：当发送方连续收到三个重复确认时，就把ssthresh慢开始门限减半，但是接下去并不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
TCP流量控制和拥塞控制区别
拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。
相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
HTTP相关
HTTP和HTTPS
HTTP 是超文本传输协议 Hyper Text Transfer Protocol, 它主要负责web server和web浏览器之间的通讯，HTTP协议把web client （浏览器）的请求发送到一个web server, 并把网页内容从web server返回到浏览器。常用请求包括get和post两种。
HTTPS 是安全超文本传输协议 Secure HTTP, 主要用于在web server和web 浏览器之间进行隐私数据的传输。
HTTP 协议包括哪些请求
GET：对服务器资源的简单请求，GET用于信息获取，而且应该是安全和幂等的。
POST：用于发送包含用户提交数据的请求，POST请求表示可能修改服务器上资源的请求。
HEAD：类似于GET请求，不过返回的响应中没有具体内容，用于获取报头
PUT：传说中请求文档的一个版本
DELETE：发出一个删除指定文档的请求
TRACE：发送一个请求副本，以跟踪其处理进程
OPTIONS：返回所有可用的方法，检查服务器支持哪些方法
CONNECT：用于ssl隧道的基于代理的请求
Get与POST的区别
GET与POST是我们常用的两种HTTP Method，二者之间的区别主要包括如下五个方面：
- 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；
- 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；
- 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的 请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为application/x-www-form-urlencoded MIME字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的请求体 中。
- 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。
- 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。
HTTP状态码
状态码是http响应里的部分，用来描述响应的状态；
2xx：成功处理请求；
3xx：重定向；
4xx：客户端错误；
5xx：服务器错误；
常见状态码：
200：请求被成功接收；
301：永久跳转，完成请求还需进一步操作；
302：临时跳转，完成请求还需进一步操作；
400：客户端请求有语法错误，不能被服务器所理解；
403：没有权限，拒绝访问；
404：访问页面不存在；
500：服务器错误；
503：服务器当前不能处理客户端请求；
Http和Https的区别
Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；
Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。
二者之间存在如下不同：
端口不同：Http与Https使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
开销：Https通信需要证书，而证书一般需要向认证机构购买；
Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。
换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。
HTTP 包含如下动作：
- 浏览器打开一个 TCP 连接
- 浏览器发送 HTTP 请求到服务器端
- 服务器发送 HTTP 回应信息到浏览器
- TCP 连接关闭
HTTP 和 HTTPS 的不同之处
- HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
- HTTP 是不安全的，而 HTTPS 是安全的
- HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
- 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
- HTTP 无需加密，而 HTTPS 对传输的数据进行加密
- HTTP 无需证书，而 HTTPS 需要认证证书
为什么需要 HTTPS ？
超文本传输协议 (HTTP) 是一个用来通过互联网传输和接收信息的协议。HTTP 使用请求/响应的过程，因此信息可在服务器间快速、轻松而且精确的进行传输。当你访问 Web 页面的时候你就是在使用 HTTP 协议，但 HTTP 是不安全的，可以轻松对窃听你跟 Web 服务器之间的数据传输。在很多情况下，客户和服务器之间传输的是敏感信息，需要防止未经授权的访问。为了满足这个要求，推出了HTTPS，也就是基于安全套接字层的 HTTP 协议。
Https加密方式（加密过程）
参考这里
对称加密
非对称加密
非对称加密+对称加密——中间人攻击
非对称加密+对称加密+CA认证 = SSL
其他
从输入网址到获得页面的过程
答案一：
- 浏览器查询DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
- 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
- TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
- 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
- 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
- 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。
答案二：
- 客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48，然后通过TCP进行封装数据包，输入到网络层。
- 在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。
- 客户端的网络层不用关系应用层或者传输层的东西，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，我不作过多的描述，无非就是通过查找路由表决定通过那个路径到达服务器。
- 客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换的IP数据包现在就可以传输了，然后发送IP数据包到达服务器的地址。
涉及各层协议？
应用层：HTTP、DNS、（DNS解析域名为目的IP，通过IP找到服务器路径，客户端向服务器发起HTTP会话）
传输层：TCP、 （HTTP会话会被分成报文段，添加源、目的端口；TCP协议进行主要工作）
网络层：IP、（ARP）、ICMP、（为数据包选择路由，IP协议进行主要工作）
链路层：PPP、（ARP）（发送IP数据包到达服务器的地址，ARP协议将IP地址转成MAC地址）
简单解释一下ARP协议的工作过程
ARP协议的用途：网络层使用的IP地址->解析出->链路层使用的硬件MAC地址
(1)首先，每个主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址之间的对应关系。
(2)当源主机要发送数据时，首先检查ARP列表中是否有对应IP地址的目的主机的MAC地址，如果有，则直接发送数据，如果没有，就向本网段的所有主机发送ARP数据包，该数据包包括的内容有:源主机IP地址，源主机MAC地址，目的主机的IP地址。
(3)当本网络的所有主机收到该ARP数据包时，首先检查数据包中的P地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和MAC地址写入到 ARP列表中，如果已经存在，则覆盖，然后将自己的MAC地址写入ARP响应包中，告诉源主机自己是它想要找的MAC地址。
(4)源主机收到ARP响应包后。将目的主机的IP和MAC地址写入ARP列表，并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。