面试之通用网络篇
本章 , 来简单的描述一下经常问到的 tcp , udp , http , https 等内容
关于 http 和 https 的介绍 , 推荐阅读 : https://blog.csdn.net/xiaoming100001/article/details/81109617
本章偏向于归纳总结… 描述一些常见的问题. 比较粗略. 一切为了面试
常见问题
-
TCP 和 UDP 的 异同点
对于这种问题… 先提出一些最明显的区别
- TCP是面向连接的, UD是不面向连接的
- 因此 TCP 具有可靠传输(通过3次握手, 4次挥手… 滑动窗口… 拥塞控制.之类的手段) , UDP仅仅是尽可能的传输
- TCP 提供的字节流的数据… UDP 使用的数据报
- 他们的报头不同. TCP更加复杂, UDP的就简单很多了(但是UDP 最长就64KB , 如果大于这个长度, 就需要应用层面自己进行编号分包处理了 )
- 共同点的话… 就是他们都是传输层的协议
-
描述一下TCP的3次握手, 和4次挥手
先描述全貌
3次握手
3次握手, 由客户端发起第一次握手(seq = x . SYN) , 服务器收到这条请求 ( 第一次握手 , 服务器确定了自己接收信息的能力 是没问题的)
第二次握手, 由服务器发送 , 是一个包含了(SYN , ACK , seq = y , ack = x+1) 回应客户端, 可以进行建立连接 (第二次握手, 客户端会收到这条请求… 客户端确定了 , 自己的发送能力, 和接收能力)
第三次握手, 由客户端发起 , 是一个包含了 (ACK, seq = x+1 , ack = y+1) 回应服务器, 确定建立连接 (第三次握手, 服务器 确定了自己发送信息的能力也是没有问题的 )
注 : 括号里的 原因, 我觉得 也可以用来解释 为什么 TCP 需要3次握手… 不是2次…或者其他的…
3次握手中的状态变化
第一次握手 , 客户端发送了请求之后, 进入SYN-SEND (请求发送的状态) , 服务器收到之后, 结束了 LISTEN (接收状态) 状态
第二次握手, 服务器发送请求之后, 进入 SYN-RCVD (请求应答状态) , 客户端收到之后 , 结束 SYN-SEND 状态
第三次握手 , 客户端发送请求好, 进入了 ESTAB-LISHED (已建立连接状态) , 服务器收到之后… 也会进入 建立连接状态. 连接完成
4次挥手
第一次挥手, 也是由客户端率先发起 (FIN , seq = x)
第二次挥手, 服务器收到之后, 也会发出一个 确认收到的包 (ACK = 1 , seq = y , ack = x +1)
第三次挥手 , 还是由服务器发起 , 当 服务器认为发送完了所有应该发送的数据之后! , 会向客户端发起 真正断开连接的请求 (FIN = 1 , ACK = 1 , seq = w , ack = x + 1)
第四次挥手 , 客户端知道了要断开连接了 , 回应服务器我已经断开连接了 ( ACK = 1 , seq = x + 1 , ack = w+1) . 服务器收到这条之后, 就进入 close 了, 关闭了
但是 ! 第四次挥手之后, 客户端为了确保 服务器收到这条消息, 不会立马断开连接 , 需要等待一个 2MSL (也就是信息一来一回最长时间) , 如果还是没有发送信息过来, 那么就关闭连接
4次握手状态的变化
第一次 客户端挥手 , 客户端进入 fin-wait-1 (终止1状态)
第二次 服务端挥手, 服务端结束了 稳定连接状态, 进入 close-wait (关闭等待状态) : 这个状态问的比较多 ,客户端接收到这次挥手之后, 进入 fin-wait-2 (终止2状态)
第三次 服务端挥手, 进入 last-ack (最后确认) 状态
第四次 , 客户端挥手, 进入 time-wait (等待时间的状态, 也就是2msl 的时间) , 之后就变成 close了 , 服务端收到消息 就变成 close了
额外
可以使用命令 netstat , 对端口进行状态排查
netstat命令各个参数说明如下：
-t : 指明显示TCP端口
-u : 指明显示UDP端口
-l : 仅显示监听套接字(所谓套接字就是使应用程序能够读写与收发通讯协议(protocol)与资料的程序)
-p : 显示进程标识符和程序名称，每一个套接字/端口都属于一个程序。
-n : 不进行DNS轮询，显示IP(可以加速操作)
netstat -ntlp //查看当前所有tcp端口·
netstat -ntulp |grep 80 //查看所有80端口使用情况·
netstat -an | grep 3306 //查看所有3306端口使用情况
-
tcp中, 拥塞控制 和 流量控制的区别
流量控制是端到端的控制，例如A通过网络给B发数据，A发送的太快导致B没法接收(B缓冲窗口过小或者处理过慢)，这时候的控制就是流量控制，原理是通过滑动窗口的大小改变来实现。
拥塞控制是A与B之间的网络发生堵塞导致传输过慢或者丢包，来不及传输。防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不至于过载。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络性能有关的所有因素。
建议阅读 : https://blog.csdn.net/ailunlee/article/details/53716367
额外总结
对称加密和非对称加密 :
- 对于密码学中, 这是2种加密方式
- 对于对称加密而言 , 它的工作流程是 , 明文—>通过秘钥—>密文----->通过秘钥---->明文
- 而非对称加密 , 则是有一个准备工作先. 先做出一个 私钥 —> 推导得出 公钥 , 然后有意思的开始了, 明文—>使用私钥加密—>密文—>只能使用公钥解密—>明文 . 反过来也一样, 明文---->使用公钥加密---->密文—>只能使用私钥解密----> 明文
- 对于对称加密而言, 非对称加密有个很重要的好处, 私钥基本不会泄露, 在泄露 公钥的情况下, 第三者 无法伪造 信息 .(因为我虽然知道公钥, 也就是服务器发出的信息 我能解密得到… 但是无法伪造一条信息发送给客户端 , 客户端发送出来的信息 无法解读…)
- 当然并不是绝对安全的… 如果 第三者自己做出一对公钥私钥… 加入到客户端和服务端中间… 偷梁换柱 , 还是能做到双方监听的
https相关 :
-
http默认使用80端口, https 默认使用 443 端口 , https 基于http协议, 通过ssl或tls提供加密数据, 验证对方身份以及数据完整性
-
它具有很多http不具有的特点
- 内容加密：采用混合加密技术，中间者无法直接查看明文内容
- 验证身份：通过证书认证客户端访问的是自己的服务器
- 保护数据完整性：防止传输的内容被中间人冒充或者篡改
-
https 采用 混合加密手段 对称加密和非对称加密都用上了 具体参考下方
-
https建立连接
- client向server发送请求，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法。
- server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集
- 随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容
- 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）
- 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥
- 传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥
- 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同
- 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息
- 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。
大体上分为…
client 和 server 各自提供一个随机数. 并且商讨好 使用哪种加密手段
server给client 一个ca的证书, 这个证书里面 包含了一个 公钥 (这里使用了非对称的加密手段) (这个证书无法被伪造 , 所以能够确保安全)
客户端通过 组合 这些随机数. 变成一个 会话秘钥… 把这个秘钥 使用 公钥进行加密 (这样 就算被中间方拦截了 也因为没有秘钥无法解析) 服务端收到 会话秘钥之后, 使用私钥进行解析, 通过 对称加密, 得到组成的 随机值 , 也对这些随机值进行组合, 得到一个会话秘钥 ,
双方使用会话秘钥进行交流一下… 没有问题 就表明建立成功…
1072
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
