计算机网络
目录
计算机网络
三次握手 建立连接
- 第一次握手： 客户机TCP 向 服务器 TCP 发送 连接请求报文段
- SYN=1 ACK=0 seq=x
- 第二次握手： 服务器TCP 收到连接请求报文段后，如同意建立连接，就向客户机发回 确认报文段 并为该TCP 连接分配TCP 缓存和变量。
- SYN=ACK=1 ,ack=x+1,seq=y
- 第三次握手： 客户机收到确认报文段，再 向服务器发出确认 ，并给该连接分配 缓存和变量。 该报文可以携带数据
- SYN=ACK=1, seq=x+1,ack=y+1
- 经过三次握手后 建立了全双工通信
- seq 标记数据段的顺序
- ack 期待收到下一个报文段的第一个数据字节的序号
- ACK 确认
- SYN 同步
- FIN 终止
TCP 三次握手的原因：
- 首要原因： 为了阻止历史的重复连接初始化，防止通信双方建立错误的连接
i. 若网络较差，发送方多次发送连接请求，若只能通信两次，则接收方无法判断这次请求是不是由于网络拥塞早就过期的连接。若能通信三次，则接收方可以发送确认序号（SEQ+1）给发送方，则发送方可以通过确认序号判断当前连接是否是历史连接，若是，则可以发RST控制消息终止这次连接。若不是 则发ACK控制消息成功建立连接。 - 另一个原因： 通信双方都要获得一个用于发送信息的初始化序列号
i. 通过三次握手 通信双方都获取到了自己期望的初始化序列号
ii. 序列号保证了 数据包的不重 不丢 保证传输顺序 - 两次握手：无法避免历史错误连接的初始化，浪费接收方资源
- 四次握手：TCP协议可同时传递ACK和SYN两个控制信息 可减少通信次数至3次
序列号的作用
- 接收方可通过序列号对重复的数据包去重
- 接收方可根据数据包的序列号对它们重新排序
- 发送方 会在对应数据包未被ACK时重新发送
四次挥手 释放连接
- 第一次挥手： 客户机 向 服务器 发送 连接释放报文段 ，停止发送数据，关闭TCP 连接
- FIN=1, seq=u
- 第二次挥手： 服务器 收到 连接释放报文段 后，向客户机发送确认报文段，此时TCP 处于半关闭状态，服务器到客户机方向的连接未关闭。
- ACK=1 ,seq=v ,ack=u+1
- 第三次挥手： 若服务器 没有数据要发送了，向客户机发送 连接释放报文段
- FIN=1 ,ACK=1, seq=w ,ack=u+1
- 第四次挥手： 客户机收到连接释放报文后，发出确认报文段 ，此时连接还未释放，进入TIME_WAIT状态 等待计时器时间结束后（2MSL Maximum Segment Lifetime 2倍的片段最大存活时间）且期间不再收到服务器发来的FIN ，TCP 释放连接；否则将继续向服务器发送ACK
- ACK=1 seq=u+1 ack=w+1
- 出现场景 ： 高并发 短连接（连接不持续）
四次挥手的两个原因:
1、让本次连接产生的所有报文从网络中消失，使得新的连接不会出现旧的连接请求，
2、确保客户机的最后一个确认报文段能到达。
TIME_WAIT （2MSL 2倍最大报文存活时间）
- 原因1： 让本连接持续时间内产生的所有报文都从网络中消失，使得下一个新连接不会出现旧连接请求报文
b) 原因2：确保最后一个报文能够到达，避免服务端一直处于LAST_ACK状态
c) 若客户端等待时间不够长 那么相同的客户端用相同的端口号与客户端建立连接会出现以下问题
i. 由于网络传输时间不确定，所以可能收到上次TCP连接中未被收到的数据段
ii. ACK可能还未被服务端接收 服务端可能还处于LAST_ACK状态，它会恢复RST终止新连接的建立
出现三次挥手的情况：客户端没有数据要发送了 可以合并ACK FIN 一起发
OSI 协议栈
- 应用层
- 表示层
- 会话层
- 传输层
- 网络层
- 数据链路层
- 物理层
TCP/IP 协议栈
- 应用层 HTTP/FTP/DNS/SMTP 为特定应用程序传输数据
- 传输层 四层交换机 四层路由器 TCP UDP 为进程提供信息传输服务 (port)
- 网络层 路由器 三层交换机 NAT ARP DHCP IP 为主机提供信息传输服务；封装成分组 (添加IP地址)
- 数据链路层 网卡 网桥 PPP HDLC CSMA/CD 为同一链路的主机提供数据传输服务；(封装成帧)
- 物理层 电缆 光纤 尽可能屏蔽传输媒体通信手段的差异 使数据链路层感觉不到差异
ARP协议
- Address Resolution Protocol（ 地址解析协议 ）
- 通过目标设备的IP地址，查询目标设备的MAC地址(唯一)，以保证通信的顺利进行。
TCP 和 IP
- TCP是传输层协议，面向连接，主要为进程提供传输服务，有具体的端口号
- IP是网络层协议，将TCP封装分组，为主机提供信息传输服务，有目标ip地址
TCP 和 UDP 的优劣
TCP 传输控制协议
- TCP 提供面向连接的服务，在传输数据之前必须建立连接，数据传送结束之后要释放连接。
- TCP 提供面向连接的 可靠传输服务
- 适用于可靠的重要场合 如FTP 文件传输协议 HTTP 超文本传输协议 TELENET 远程登录
UDP 用户数据报协议
- UDP 是一个无连接的 非可靠的传输层协议
- 它在IP 的基础上提供两个附加服务： 多路复用 和 对数据的错误检查
- 传输数据的时候 无需建立连接
- 适合实时传输协议 RTP
TCP性能问题的原因
- TCP拥塞控制会在丢包时（超时）将拥塞窗口（cwnd）设置为1，减少能够发送的是数据段的数量，但丢包不一定是拥塞，可能仅是网络状况差
- TCP三次握手带来了额外的开销，增加首次传输数据的网络时延
- TCP超时重传机制 可能会传输已经成功接收的数据段 造成带宽浪费
- 使用UPD可以构建更加优异灵活的传输协议 例如QUIC协议
Http 应用层协议
- http 安全问题：
- 明文通信，内容可能被窃听
- 不验证通信方身份，身份可能被伪装
- 无法验证报文完整性，报文可能被篡改
- https=http+ ssl
- ssl=secure sockets layer 使用隧道进行通信
- https 具有加密（防窃听），认证（防伪装），完整性保护（防篡改）
-
加密
- 对称密钥加密RSA：加密解密同一密钥 运算速度快 但无法将密钥安全的传输给对方
- 非对称密钥加密： 加密和解密使用不同的密钥 公钥和私钥 安全的传递公钥 再用私钥解密，但运算速度慢
- https使用的是对称密钥与非对称密钥混合加密的形式，使用非对称加密方式传递 对称密钥方式所需要的secret key保证了安全性；双方都有secret key时 就可以使用对称加密方式进行通信 保证了效率
-
认证
- 数字证书认定机构CA: 对通信双方进行认证
-
完整性保护
- ssl 通过报文摘要功能进行完整性保护
从浏览器输入url 到页面显示
- 浏览器将url交给DNS做域名解析 找到真实的IP地址 向服务器发起请求
- 服务器接收请求 返回数据，浏览器接收数据
- 浏览器对接收到的数据进行解析，渲染页面
略详细版本
-
浏览器地址栏输入URL
-
浏览器查看请求资源是否在缓存中并且新鲜，若有缓存且新鲜则可以直接对缓存的数据进行解析，渲染页面
-
否则，解析URL获取协议、主机、端口等并组装一个http get请求报文
-
接着获取主机的ip地址，先在缓存中看是否缓存在该域名的ip地址，若无用DNS做域名解析
-
建立TCP链接 发送HTTP请求
-
服务器收到HTTP请求后 做查询等操作 将响应报文通过TCP连接 返回给浏览器
-
浏览器接收到HTTP响应后，可以关闭TCP或保留TCP重用
-
浏览器对接收到的数据进行解析 渲染
-
HTTP是无状态协议 需要cookies和section 缓存状态
HTTP 状态码
- 200 请求成功
- 301 资源被转移到其他URL
- 404 请求资源不存在
- 500 内部服务器错误
TCP 可靠传输
- TCP使用超时重传实现可靠传输，加权平均往返时间位RTTs， RTT为一次确认所经过的时间。使用指数滑动平均计算(EMA)
- 超时时间等于
RTTd代表偏差的加权平均
TCP流量控制（通过接收方确认报文段的窗口字段可控制发送端的窗口大小，从而影响发送端的发送速率，保证对方来得及接收）
a) 发送方窗口原理： 发送窗口内的字节都允许被发送，当发送方窗口左部的字节已经发送且收到确认后 则发送窗口可以左移到左部第一个字节不是发送且已确认的状态
b) 接收方窗口原理：接收方对窗口内最后一个有序到达的字节进行确认
TCP拥塞控制（拥塞重传时 降低整体网络拥塞程度 避免拥塞程度更高）
a) 慢开始：初始时拥塞窗口（cwnd）为1，收到确认后将cwnd加倍
b) 拥塞避免：当cwnd超过慢开始门限ssthresh时，每轮只将cwnd加1
c) 超时时（等待确认时间超过RTO）：将ssthresh=cwnd/2 重新执行慢开始 cwnd=1
d) 当丢失个别报文段时（接收方接收到3个重复确认的M2）：执行快重传和快恢复，立即重传M3，ssthresh=cwnd/2 , cwnd设置为ssthresh
