网络基础

Published: January 01, 0001 by

• Categories:
• 学习清单 8

• Tags:
• 学习清单 8

• 1.OSI与TCP/IP 模型
• 2.常见网络服务分层
• 3.TCP
  • 3.1 三次握手
    • 3.1.1 三次握手过程
    • 3.1.2 为什么需要三次
    • 3.1.3 为什么两次不行
  • 3.2 四次挥手
    • 3.2.1 四次挥手过程
    • 3.2.2 为什么四次
    • 3.2.3 如何查看TIME-WAIT状态的链接数量
    • 3.2.4 为什么会TIME-WAIT过多？解决方法是怎样的
  • 3.3 TCP滑动窗口，拥塞控制
  • 3.4 TCP粘包原因和解决方法
    • 3.4.1 TCP粘包是指
    • 3.4.2 发送方原因
    • 3.4.3 接收方原因
    • 3.4.4 ​解决粘包问题
• 4.TCP与UDP区别及场景
• 5.HTTP协议
  • 5.1 HTTP协议1.0_1.1_2.0
    • 5.1.1 http1.0和http1.1的主要区别
    • 5.1.2 http1.1和http2.0的主要区别
  • 5.2 HTTP与HTTPS之间的区别
    • 5.2.1 HTTPS链接建立的过程
    • 5.2.2 对称加密算法
    • 5.2.3 非对称加密算法
  • 5.3 Get和Post请求区别
  • 5.4 HTTP常见响应状态码
  • 5.5 重定向和转发区别
    • 5.5.1 重定向(redirect)
    • 5.5.2 ​转发(forward)
  • 5.6 Cookie和Session区别
  • 5.7 浏览器输入URL过程

1.OSI与TCP/IP 模型

• OSI七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
• TCP/IP五层：物理层、数据链路层、网络层、传输层、应用层

2.常见网络服务分层

• 应用层：HTTP、SMTP、DNS、FTP
• 传输层：TCP 、UDP
• 网络层：ICMP 、IP、路由器、防火墙
• 数据链路层：网卡、网桥、交换机
• 物理层：中继器、集线器

3.TCP

3.1 三次握手

3.1.1 三次握手过程

• 客户端——发送带有SYN（syn=x）标志的数据包——服务端 一次握手 Client进入syn_send状态
• 服务端——发送带有SYN（syn=y）+ACK（ack=x+1）标志的数据包——客户端 二次握手 服务端进入syn_rcvd
• 客户端——发送带有ACK（ack=y+1）标志的数据包——服务端 三次握手 连接就进入Established状态

状态解释

• YN_RCVD（服务器）: 这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
• SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
• ESTABLISHED：这个容易理解了，表示连接已经建立了。

3.1.2 为什么需要三次

主要是为了建立可靠的通信信道，保证客户端与服务端同时具备发送、接收数据的能力

3.1.3 为什么两次不行

• 防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源
• 两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手，至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认）

3.2 四次挥手

3.2.1 四次挥手过程

• 客户端——发送带有FIN标志的数据包——服务端，关闭与服务端的连接，也就是客户端告诉服务端：我已经不会再给你发数据了(当然，在FIN包之前发送出去的数据，如果没有收到对应的ACK确认报文，客户端依然会重发这些数据)，但是，此时客户端还可以接受数据。客户端进入FIN-WAIT-1状态
• 服务端收到这个FIN，它发回⼀个ACK，确认序号为收到的序号加1，服务端就进入了CLOSE-WAIT状态（这种状态的含义其实是表示在等待关闭）
• 服务端——发送⼀个FIN数据包——客户端，关闭与客户端的连接，也就是告诉客户端，我的数据也发送完了，不会再给你发数据了。客户端就进入FIN-WAIT-2状态
• 客户端收到这个FIN，发回ACK报⽂确认，并将确认序号设置为收到序号加1，客户端进入TIME-WAIT状态（为了解决网络的丢包和网络不稳定所带来的其他问题，确保连接方能在时间范围内，关闭自己的连接）

状态解释：

• FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
• FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
• TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
  • 注:MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间,每个具体的TCP实现都必须选择一个确定的MSL值.RFC 1122建议是2分钟,但BSD传统实现采用了30秒.TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟.
  • 结论：在TIME_WAIT下等待2MSL，只是为了尽最大努力保证四次握手正常关闭。确保老的报文段在网络中消失，不会影响新建立的连接.
• CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
• CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
• LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。

3.2.2 为什么四次

​因为需要确保客户端与服务端的数据能够完成传输。

3.2.3 如何查看TIME-WAIT状态的链接数量

netstat -an |grep TIME_WAIT|wc -l 查看连接数等待time_wait状态连接数

3.2.4 为什么会TIME-WAIT过多？解决方法是怎样的

• 可能原因：高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接
• 解决：负载均衡服务器；Web服务器首先关闭来自负载均衡服务器的连接

3.3 TCP滑动窗口，拥塞控制

• TCP通过：应用数据分割、对数据包进行编号、校验和、流量控制、拥塞控制、超时重传等措施保证数据的可靠传输；

• 拥塞控制目的：为了防止过多的数据注入到网络中，避免网络中的路由器、链路过载

• 拥塞控制过程：TCP维护一个拥塞窗口，该窗口随着网络拥塞程度动态变化，通过慢开始、拥塞避免等算法减少网络拥塞的发生。

3.4 TCP粘包原因和解决方法

3.4.1 TCP粘包是指

发送方发送的若干包数据到接收方接收时粘成一包

3.4.2 发送方原因

• TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量）：
• 收集多个小分组，在一个确认到来时一起发送、导致发送方可能会出现粘包问题

3.4.3 接收方原因

• TCP将接收到的数据包保存在接收缓存里，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

3.4.4 ​解决粘包问题

最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪，通过使用某种方案给出边界，例如：

• 发送定长包。每个消息的大小都是一样的，接收方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
• 包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
• 包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。

4.TCP与UDP区别及场景

类型	特点	性能	应用场景	首部字节	基于此的协议
TCP	面向连接、可靠、字节流	传输效率慢、所需资源多	文件、邮件传输	20-60	HTTP、FTP、SMTP
UDP	无连接、不可靠、数据报文段	传输效率快、所需资源少	语音、视频、直播	8个字节	RIP、DNS、SNMP

5.HTTP协议

5.1 HTTP协议1.0_1.1_2.0

• HTTP1.0：服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）
• HTTP1.1：KeepAlived长连接避免了连接建立和释放的开销；通过Content-Length来判断当前请求数据是否已经全部接受（有状态）
• HTTP2.0：引入二进制数据帧和流的概念，其中帧对数据进行顺序标识；因为有了序列，服务器可以并行的传输数据。

5.1.1 http1.0和http1.1的主要区别

• 缓存处理：1.1添加更多的缓存控制策略（如：Entity tag，If-Match）
• 网络连接的优化：1.1支持断点续传
• 错误状态码的增多：1.1新增了24个错误状态响应码，丰富的错误码更加明确各个状态
• Host头处理：支持Host头域，不在以IP为请求方标志
• 长连接：减少了建立和关闭连接的消耗和延迟。

5.1.2 http1.1和http2.0的主要区别

• 新的传输格式：2.0使用二进制格式，1.0依然使用基于文本格式
• 多路复用：连接共享，不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）
• header压缩：由于1.X中header带有大量的信息，并且得重复传输，2.0使用encoder来减少需要传输的header大小
• 服务端推送：同google的SPDUY（1.0的一种升级）一样

5.2 HTTP与HTTPS之间的区别

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

HTTP	HTTPS
默认端口80	HTTPS默认使用端口443
明文传输、数据未加密、安全性差	传输过程ssl加密、安全性较好
响应速度快、消耗资源少	响应速度较慢、消耗资源多、需要用到CA证书

5.2.1 HTTPS链接建立的过程

1. 首先客户端先给服务器发送一个请求
2. 服务器发送一个SSL证书给客户端，内容包括：证书的发布机构、有效期、所有者、签名以及公钥
3. 客户端对发来的公钥进行真伪校验，校验为真则使用公钥对对称加密算法以及对称密钥进行加密
4. 服务器端使用私钥进行解密并使用对称密钥加密确认信息发送给客户端
5. 随后客户端和服务端就使用对称密钥进行信息传输

5.2.2 对称加密算法

双方持有相同的密钥，且加密速度快，典型对称加密算法：DES、AES

5.2.3 非对称加密算法

密钥成对出现（私钥、公钥），私钥只有自己知道，不在网络中传输；而公钥可以公开。相比对称加密速度较慢，典型的非对称加密算法有：RSA、DSA

5.3 Get和Post请求区别

方法	描述
GET	HTTPS默认使用端口443
POST	传输过程ssl加密、安全性较好
PUT	响应速度较慢、消耗资源多、需要用到CA证书
HEAD	类似GET请求，返回的响应中没有具体的内容，用于获取报头
DELETE	请求服务器删除指定标识的资源
OPTIONS	可以用来向服务器发送请求来测试服务器的功能性
TRACE	回显服务器收到的请求，用于测试或诊断
CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

get和post的区别：

差异点	get	post
可见性	数据在URL中对所有人可见	数据不会显示在URL中
安全性	与post相比，get的安全性较差，因为所发送的数据是URL的一部分	安全，因为参数不会被保存在浏览器历史或web服务器日志中
数据长度	受限制，最长2kb	无限制
编码类型	application/x-www-form-urlencoded	multipart/form-data
缓存	能被缓存	不能被缓存

5.4 HTTP常见响应状态码

• 100：Continue — 继续。客户端应继续其请求。
• 200：OK — 请求成功。一般用于GET与POST请求。
• 301：Moved Permanently — 永久重定向。
• 302：Found — 暂时重定向。
• 400：Bad Request — 客户端请求的语法错误，服务器无法理解。
• 403：Forbideen — 服务器理解请求客户端的请求，但是拒绝执行此请求。
• 404：Not Found — 服务器无法根据客户端的请求找到资源（网页）。
• 500：Internal Server Error — 服务器内部错误，无法完成请求。
• 502：Bad Gateway — 作为网关或者代理服务器尝试执行请求时，从远程服务器接收到了无效的响应。

5.5 重定向和转发区别

5.5.1 重定向(redirect)

• 地址栏发生变化
• 重定向可以访问其他站点（服务器）的资源
• 重定向是两次请求。不能使用request对象来共享数据

5.5.2 ​转发(forward)

• 转发地址栏路径不变
• 转发只能访问当前服务器下的资源
• 转发是一次请求，可以使用request对象共享数据

5.6 Cookie和Session区别

• Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但两者有所区别：
• Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
• cookie不是很安全，别人可以分析存放在本地的COOKIE并进行欺骗,考虑到安全应当使用session。
• Cookie ⼀般⽤来保存⽤户信息，Session 的主要作⽤就是通过服务端记录⽤户的状态

5.7 浏览器输入URL过程

过程：DNS解析、TCP连接、发送HTTP请求、服务器处理请求并返回HTTP报文、浏览器渲染、结束

过程	使用的协议
1、浏览器查找域名DNS的IP地址DNS查找过程（浏览器缓存、路由器缓存、DNS缓存)	DNS：获取域名对应的ip
2、根据ip建立TCP连接	TCP：与服务器建立连接
3、浏览器向服务器发送HTTP请求	HTTP：发送请求
4、服务器响应HTTP响应	HTTP
5、浏览器进行渲染