计算机网络基础知识总结

此文章为网上知识点个人整合，一些知识点附带原文链接，侵删

0. OSI：七层模型、五层模型、TCP/IP四层模型

https://www.cnblogs.com/gdayq/p/5797645.html

https://blog.csdn.net/yaopeng_2005/article/details/7064869

1. http与https

1.1 http状态码

状态码的类别：

• 1XX Informational（信息性状态码） 接受的请求正在处理
• 2XX Success（成功状态码） 请求正常处理完毕
• 3XX Redirection（重定向状态码） 需要进行附加操作以完成请求
• 4XX Client Error（客户端错误状态码） 服务器无法处理请求
• 5XX Server Error（服务器错误状态码） 服务器处理请求出错

1XX表示:消息

这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。 这些状态码代表的响应都是信息性的，标示客户应该采取的其他行动。

• “100″ : Continue 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分.
• “101″ : witching Protocols 服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的那些协议。: 只有在切换新的协议更有好处的时候才应该采取类似措施.
• “102″: Processing 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

2XX表示:成功

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

• “200″ : OK
• “201″ : Created 已创建
• “202″ : Accepted 接收
• “203″ : Non-Authoritative Information 非认证信息
• “204″ : No Content 无内容
• “205″ : Reset Content 重置内容
• “206″ : Partial Content 服务器已经成功处理了部分GET请求。类似于FlashGet或者迅雷这类的HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
• “207″: Multi-Status 由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码.

3XX表示: 游览器重定向

这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。

• “300″ : Multiple Choices 多路选择
• “301″ : Moved Permanently 永久转移
• “302″ : Found 暂时转移
• “303″ : See Other 参见其它
• “304″ : Not Modified 未修改
• “305″ : Use Proxy 使用代理
• “306″: Switch Proxy 在最新版的规范中，306状态码已经不再被使用。
• “307″ : Temporary Redirect 请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

4XX表示: 客户端错误

这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

• “400″ : Bad Request 错误请求
• “401″ : Unauthorized 未认证
• “402″ : Payment Required 需要付费
• “403″ : Forbidden 禁止
• “404″ : Not Found 请求失败，请求所希望得到的资源未被在服务器上发现
• “405″ : Method Not Allowed 方法不允许
• “406″ : Not Acceptable 不接受
• “407″ : Proxy Authentication Required 需要代理认证
• “408″ : Request Time-out 请求超时
• “409″ : Conflict 冲突
• “410″ : Gone 失败
• “411″ : Length Required 需要长度
• “412″ : Precondition Failed 条件失败
• “413″ : Request Entity Too Large 请求实体太大
• “414″ : Request-URI Too Large 请求URI太长
• “415″ : Unsupported Media Type 不支持媒体类型
• “416″ : Requested range not satisfiable 如果请求中包含了Range请求头，并且Range中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义If-Range请求头，那么服务器就应当返回416状态码。
• “417″ : Expectation Failed 在请求头Expect中指定的预期内容无法被服务器满足
• “421 “:There are too many connections from your internet address 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址.
• “422″: Unprocessable Entity 请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）
• “423″: Locked 当前资源被锁定。（RFC 4918 WebDAV）
• “424″: Failed Dependency 由于之前的某个请求发生的错误，导致当前请求失败，例如PROPPATCH。（RFC 4918 WebDAV）
• “425″: Unordered Collection 在WebDav Advanced Collections草案中定义，但是未出现在《WebDAV顺序集协议》（RFC 3658）中。
• “426″:Upgrade Required 客户端应当切换到TLS/1.0。（RFC 2817）
• “449″: Retry With 由微软扩展，代表请求应当在执行完适当的操作后进行重试。

5XX表示: 服务器错误

这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生

• “500″ : Internal Server Error 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现
• “501″ : Not Implemented 未实现
• “502″ : Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应
• “503″ : Service Unavailable 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。
• “504″ : Gateway Time-out 网关超时
• “505″ : HTTP Version not supported 服务器不支持，或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。
• “506” : Variant Also Negotiates 由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。
• “507” : Insufficient Storage 服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV（RFC 4918）
• “509” : Bandwidth Limit Exceeded 服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。
• “510” : Not Extended 获取资源所需要的策略并没有没满足。（RFC 2774）

1.2 http和https的区别

https://blog.csdn.net/qq_38905818/article/details/104904496?spm=1001.2014.3001.5501

• https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用
• http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议
• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
• http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

1.2.1 对称加密和非对称加密

关于SSL中的对称加密和非对称加密

对称加密含义：对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）,这种方法在密码学中叫做对称加密算法。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。

非对称加密含义：非对称加密为数据的加密与解密提供了一个非常安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。比如，你向银行请求公钥，银行将公钥发给你，你使用公钥对消息加密，那么只有私钥的持有人–银行才能对你的消息解密。与对称加密不同的是，银行不需要将私钥通过网络发送出去，因此安全性大大提高。

常用的对称加密：

1). DES: java6只支持例56位秘钥长度,通过BounvyCastle可以将秘钥长度增加至64位。例：http://blog.csdn.net/u013791374/article/details/51970860

2). 三重DES:作为DES的改良（核心还是DES），针对DES秘钥长度偏短，迭代次数偏少，等问题进行了改良，秘钥长度从56位提升到112或168位，优点：抗穷举的能力显著增加，缺点：加密低效，处理速度较慢。例：http://blog.csdn.net/u013791374/article/details/51971188

3). AES:AES的基本要求是： 比三重DES快、至少与三重DES一样安全、数据分组长度为128比特、密钥长度为128/192/256比特。优点：秘钥建立时间短，存储要求低。

常用的非对称加密：

1). RSA:秘钥长度1024位。例：

https://blog.csdn.net/u011583927/article/details/81272265

数字签名：

总结:

（1） 对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。

（2） 非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

（3） 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

1.3 get和post请求区别

1.4 http 1.0-1.1-2.0-3.0区

https://blog.csdn.net/weixin_34235371/article/details/88910200

http 1.0	无状态、无连接
http 1.1	1.持久连接 2.请求管道化 3.增加缓存处理（新的字段如cache-control）4.增加Host字段、支持断点传输等（把文件分成几部分）
http 2.0	1.二进制分帧 2.多路复用（或连接共享）3.头部压缩 4.服务器推送

3 HTTP 3.0 (QUIC)
QUIC (Quick UDP Internet Connections), 快速 UDP 互联网连接。
QUIC是基于UDP协议的。

两个主要特性：
（1）线头阻塞(HOL)问题的解决更为彻底：
基于TCP的HTTP/2，尽管从逻辑上来说，不同的流之间相互独立，不会相互影响，但在实际传输方面，数据还是要一帧一帧的发送和接收，一旦某一个流的数据有丢包，则同样会阻塞在它之后传输的流数据传输。而基于UDP的QUIC协议则可以更为彻底地解决这样的问题，让不同的流之间真正的实现相互独立传输，互不干扰。
（2）切换网络时的连接保持：
当前移动端的应用环境，用户的网络可能会经常切换，比如从办公室或家里出门，WiFi断开，网络切换为3G或4G。基于TCP的协议，由于切换网络之后，IP会改变，因而之前的连接不可能继续保持。而基于UDP的QUIC协议，则可以内建与TCP中不同的连接标识方法，从而在网络完成切换之后，恢复之前与服务器的连接。

2. TCP和UDP

2.1 TCP和UDP区别

1. TCP面向连接 （如打电话要先拨号建立连接）; UDP是无连接的，即发送数据之前不需要建立连接
2. TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付(TCP通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。)
3. UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。QQ
4. TCP对系统资源要求较多，UDP对系统资源要求较少。

	TCP	UDP
连接	面向链接（3次握手）	无连接，面向报文段
可靠性	可靠	不可靠
通信方式	点到点	1vN；NvN；1v1
速度	慢	快
应用场合	大量数据传输	少量数据
占用系统资源	多	少
实时性		强（QQ，实时游戏）

2.2为什么UDP有时比TCP更有优势?

UDP以其简单、传输快的优势，在越来越多场景下取代了TCP,如实时游戏。

（1）网速的提升给UDP的稳定性提供可靠网络保障，丢包率很低，如果使用应用层重传，能够确保传输的可靠性。

（2）TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，建立了繁琐的握手过程，由于TCP内置的系统协议栈中，极难对其进行改进。

采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大，基于UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响。

https://blog.csdn.net/qq_40927789/article/details/80607610

TCP协议可靠性保障四大机制：

• 确认应答机制（ACK）
• 超时重传机制（去重机制、快重传）
• 流量控制：滑动窗口
• 拥塞控制（慢启动、拥塞窗口）

2.3 TCP/IP三次握手，四次挥手

https://blog.csdn.net/qq_38950316/article/details/81087809

为什么不是2次或者4次握手？

如果两次，那么B无法确定B的信息A是否能收到，所以如果B先说话，可能后面的A都收不到，会出现问题 。

如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。

为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是因为服务端在LISTEN状态下，收到客户端发送的断开连接的FIN报文后，可能会有数据未发送完成，需要继续发送，因此不能将确认消息和请求关闭消息同时发送，而是会先关闭接收服务回复确认消息，然后继续发送未完消息到客户端，直到发送结束，再发送请求关闭消息.

3. Nginx和Tomcat区别

https://www.cnblogs.com/flypie/p/5153702.html

动静态资源分离——运用Nginx的反向代理功能分发请求：所有动态资源的请求交给Tomcat，而静态资源的请求（例如图片、视频、CSS、JavaScript文件等）则直接由Nginx返回到浏览器，这样能大大减轻Tomcat的压力。

负载均衡，当业务压力增大时，可能一个Tomcat的实例不足以处理，那么这时可以启动多个Tomcat实例进行水平扩展，而Nginx的负载均衡功能可以把请求通过算法分发到各个不同的实例进行处理

严格的来说，Apache/Nginx 应该叫做「HTTP Server」；而 Tomcat 则是一个「Application Server」，或者更准确的来说，是一个「Servlet/JSP」应用的容器（Ruby/Python 等其他语言开发的应用也无法直接运行在 Tomcat 上）。

正向代理/反向代理：

4. HTTP和TCP保活计时器

• HTTP的Keepalive，顾名思义，目的在于延长连接的时间，以便在同一条连接中传输多个HTTP请求。

• HTTP服务器一般会提供Keepalive Timeout参数，用来决定连接保持多久，什么时候关闭连接。

• 当连接使用了Keepalive功能时，对于客户端发送过来的一个请求，服务器端会发送一个响应，然后开始计时，

• 如果经过Timeout时间后，客户端没有再发送请求过来，服务器端就把连接关了，不再保持连接了。

• TCP的Keepalive，是挂羊头卖狗肉的，目的在于看看对方有没有发生异常，如果有异常就及时关闭连接。

• 当传输双方不主动关闭连接时，就算双方没有交换任何数据，连接也是一直有效的。

• 如果这个时候对端、中间网络出现异常而导致连接不可用，本端如何得知这一信息呢？

• 答案就是保活定时器。它每隔一段时间会超时，超时后会检查连接是否空闲太久了，如果空闲的时间超过了设置时间，就会发送探测报文。然后通过对端是否响应、响应是否符合预期，来判断对端是否正常，如果不正常，就主动关闭连接，而不用等待HTTP层的关闭了。

5. url在游览器的流程

https://blog.csdn.net/m0_37989980/article/details/112524733

DNS:

6. Cookies 和session的区别是

1、Cookies 和session的区别是：cookie数据保存在客户端，session数据保存在服务器端。

2、两个都可以用来存私密的东西，同样也都有有效期的说法,区别在于session是放在服务器上的，过期与否取决于服务期的设定，cookie是存在客户端的，过去与否可以在cookie生成的时候设置进去。

​ (1)、cookie数据存放在客户的浏览器上，session数据放在服务器上 ；

​ (2)、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session ；

​ (3)、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当 使用COOKIE ；

​ (4)、单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K；

​ (5)、所以将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中。

3、cookie和session的共同之处在于：cookie和session都是用来跟踪浏览器用户身份的会话方式。

4、cookie 是一种发送到客户浏览器的文本串句柄，并保存在客户机硬盘上，可以用来在某个WEB站点会话间持久的保持数据。

7. 多路复用

多路网络连接复用一个io线程

IO 多路复用是5种I/O模型中的第3种，对各种模型讲个故事，描述下区别：

故事情节为：老李去买火车票，三天后买到一张退票。参演人员（老李，黄牛，售票员，快递员），往返车站耗费1小时。

1.阻塞I/O模型

老李去火车站买票，排队三天买到一张退票。

耗费：在车站吃喝拉撒睡 3天，其他事一件没干。

2.非阻塞I/O模型

老李去火车站买票，隔12小时去火车站问有没有退票，三天后买到一张票。

耗费：往返车站6次，路上6小时，其他时间做了好多事。

3.I/O复用模型

1.select/poll

https://link.zhihu.com/?target=http%3A//1.select/poll

老李去火车站买票，委托黄牛，然后每隔6小时电话黄牛询问，黄牛三天内买到票，然后老李去火车站交钱领票。

耗费：往返车站2次，路上2小时，黄牛手续费100元，打电话17次

2.epoll

老李去火车站买票，委托黄牛，黄牛买到后即通知老李去领，然后老李去火车站交钱领票。

耗费：往返车站2次，路上2小时，黄牛手续费100元，无需打电话

4.信号驱动I/O模型

老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李，然后老李去火车站交钱领票。

耗费：往返车站2次，路上2小时，免黄牛费100元，无需打电话

5.异步I/O模型

老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李并快递送票上门。

耗费：往返车站1次，路上1小时，免黄牛费100元，无需打电话

1同2的区别是：自己轮询
2同3的区别是：委托黄牛
3同4的区别是：电话代替黄牛
4同5的区别是：电话通知是自取还是送票上门

I/O模型
老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李，然后老李去火车站交钱领票。

耗费：往返车站2次，路上2小时，免黄牛费100元，无需打电话

8. 常见端口

6379：Redis
3306：Mysql
8080：Tomcat
80：Http
443：Https
21：FTP
22：SSH
23：Telnet