目录
基于传输层的协议
网络的原生问题
- 我们知道传输层是基于主机和主机可以通信的前提下，让进程可以和进程进行通信，那么传输层的实现要基于网络层的实现
- 在网络中的数据，是经由路由器之间，一跳一跳的，传送到目标主机上带来的两个问题（基于网络层的视角的讨论）
- 为了解决这些问题，让传输层和应用层的有志人士去解决
网络传输的不可靠
- 发送的数据，对方不能保证一定能收到
- 不能保证严格按照发送时的顺序被对方一定被接收（因为路由器的原因，数据发送的路径可能不一样和速度不一样，比如我们去北京早上A做汽车，B中文坐高铁，C下午做飞机，所以可能到达北京的顺序是BAC 也有可能是ABC BCA）
网络是不安全的
- 发送的所有数据，沿途的路由器都可以进行查看或者修改，窃听，篡改
- 别人可以伪造你发送数据
UDP协议
- 用户报文协议，它是一个很简单的传输层协议，它只是做到了传输层的最基本的职责（在主机和主机能连接的情况下，实现进程到进程的连接）
- 特点 1无连接 2不可靠传输 3面向数据报 4 收缓冲区，无发送缓冲区，但是成本便宜
- UDP的不可靠：并不是UDP协议做了什么，变得不可靠了，而是因为UDP什么都没做，把网络层的不可靠性直接表达给应用层，所以在应用层的角度，我们才说UDP是不可靠的
UDP的工作机制
- UDP的报头，所有网络协议的报头都具备的职责：如何解包（怎么把数据中方header(报头)，和payload（数据内容）分开）
- 分用的问题，也就是怎么实现应用层到应用层的问题
例子
- 我们要发货的物品就是payload，而包装的袋子和袋子上的订单内容就是header
- 我们就是享受UDP服务的进程
- 送货的汽车是网络层提供的服务
UDP报头的格式
UDP首部有8个字节，由4个字段构成，每个字段都是两个字节，
- 1.源端口： 源端口号，需要对方回信时选用，不需要时全部置0.
- 2.目的端口：目的端口号，在终点交付报文的时候需要用到。
- 3.长度：UDP的数据报的长度（包括首部和数据）其最小值为8（只有首部）
- 4.校验和：检测UDP数据报在传输中是否有错，有错则丢弃（基本原理就是利用hash函数，只要是相同的是数据，经过函数处理，哈希值肯定是一样的）
缓冲区的概念
- 我们所谓的分层，都是逻辑上的概念，在硬件上来说，我们只有内存（用户态管理的内存和内核态管理的内存）
- 我们把这一块内存区域，用来存放发送或者接收的数据，称为缓冲区
- 其UDP只有收缓冲区（就想我们寄快递，有菜鸟驿站给我们暂存）
在应用层的UDP协议中，是没有发送缓冲区的，如果UDP发送数据成功，代表什么现象呢？
UDP数据只是发送到网络上了（正在传输中），就像我们生活中，我们寄信成功了，只是代表我们把信寄出去了，不知道信在哪有没有被收到
UDP发送流程
- 从应用层收到数据（将数据从应用层的内存区域（用户态）复制到内核的内存区域中）
- 准备header部分 1源端口号（socket对象中带着（本地进程的端口））2 目标端口（应用层负责填写）3 UDP长度（header长度+数据长度）通过计算 4 checksum,校验和，也是通过计算
- header+payload得到报文段（datagram）
- 等网络层发送成功（意味着数据到网卡了）
- 通知应用层发送成功
UDP的接收流程
- 从网络层收到一个新的包裹（UDP Datagram）
- 根据定长（8个字节），擦拆分为headerz和payload——解包
- 读取header的四个字段，源端口，目标端口，长度，校验和
- 判断下长度是否正确，如果长度不正确的情况下的包直接扔掉，谁都不需要通知（体现出了不可靠）
- 判断校验和是否正确（判断数据是否有没有在无意中损坏），如果有问题，直接扔掉
- 把payload放到接收缓冲区中，相关信息也放在其中
- 通知应用层来取信息（根据目标端口来找到对应的进程）
- 等着应用层来从接收缓冲区接收信息
- 如果长时间不取，也可以将数据扔掉
TCP协议
特点
- 有连接
- 可靠传输
- 面向字节流
- 有接收缓冲区，也有发送缓冲区
- 大小不限
TCP与UDP最大的不同就是保证了基于主机和主机已经连接的情况下，进程与进程之间可靠传输,保证的是可靠性，不是安全性
什么是可靠性
- TCP会尽自己所能，尽量将数据发送给对方，但是并不能保证100%发给对方
- TCP会在数据发送不给对方的情况下，给应用层一个错误的通知
- TCP可以保障接收方会严格按照发送时的数据顺序接收
- TCP保障数据不会出现无意间的损害（UDP也做到了这点）
- TCP尽可能的在维护网络的质量
提供的机制
确认机制(我给你发数据，你得告诉我你有没有收到数据)
出现的问题
- 如果发送方发送了很多数据，怎么确定对方收到的是那一份数据
- 如果没有收到对方的确认（假定对方是正常工作），接下来该怎么办
一般称为TCP的数据为段(segment),segemt=header+payload
- URG-----紧急信号表明紧急指针(urgent pointer),它能告诉系统此报文段有紧急数据,应尽快传送。
- ACK-----确认信号只有当ACK=1时确认号字段才有效。当ACK=0时,确认号无效。
- PSH-----推送信号接收TCP推送bit置1的报文段，则尽快交付给接收应用进程，无需缓存。
- RST-----复位信号当RST=1时,表明TCP连接中有严重错误，则释放连接，然后再重新建立连接。
- SYN-----同步信号SYN表示一个连接请求或连接接收报文。
- FIN-----终止信号用来释放一个连接。当FIN=1,表明报文段的发送端的数据已发送完毕,要求释放运输连接。
解决方法
对数据进行编号
- 通过对数据进行编号，来识别发送的是那个数据，也对确认的回应确认数据进行编号，来表明确认的是那份数据
- SN是序列号
- ASN是确认序列号
- 对于发送的第一个字节的SN（初始化序列号ISN）一般不是0，而是一个随机数 ,但是相对发送的数据来说是0
- 对于SN的填写，我们只需要去填写第一个字节的数据的编号，因为segment中带有数据的长度，所以确定了第一个字节数据的编号，肯定能确定后面数据的编号
关于ISN的确认
关于TCP的身份的转换
- 我们知道TCP的数据段可以被当作发送给接收方的数据，也可以作为接收方回应发送方的回应信息，所以需要身份的转换
- TCP身份的转换靠ACK标志位来实现
- ACK占一个比特大小
ASN的填写方式
对数据进行重发
当没有收到回应的几种情况
- 可能接收方还没有接收到发送的数据，所以没有应答（1数据还在路上，暂时没有到达对方）（2数据已经在路上丢失，永远不会到达）
- 对方已经收到发送的数据，也应答了，但是发送方没有接收到（1应答可能还在路上，暂时没有到达）（2应答已经丢失，永远不可能到达）
对于1.1和2.1的解决，就是设置合适的超时时间来避免
对于1.2和2.2的解决方法，重复数据包是否会有风险
- 对于第二种应答丢失的，我们重复数据包会导致接收方收到重复的数据
- 但是TCP可以通过SN来分辨出重复的数据包，然后丢弃重复的数据包，虽然丢弃重复的数据包，但是依然会发送ack确认信息
- 所以对于1.2和2.2都可以进行发送重复数据包进行解决
对于第三种情况的解决
- 尝试几次的重复发数据包，都没有接收到确认信号，那么就是停止发送,通知应用层，发送失败（JAVA中会抛出一个异常）
- 还会有最后一次发送来联系对方，通知对方已经放弃发送
关于发送和接收的缓冲区
- 因为TCP要做到确认应答机制，所以对于已经发出去的数据，我们肯定需要保留，因为成功发送，不代表对方成功接收，只有收到确认信号，才能确认对方接收，所以这些发送的数据要暂存在发送缓冲区
- TCP也有接收缓冲区，因为接收的数据，应用层也不是立即要取走
关于应用层使用TCP发送数据成功，代表什么
关于TCP的管理
- 对于一条TCP，内部针对每一条TCP的通信链路，维护一组数据：（ISN,当前ISN,当前ASN,发送缓冲区，接收缓冲区，五元组信息
- 为了使TCP可靠，在正式的数据通信之前，需要和对方的TCP进行一定的同步（synchronize）操作，来互相交换一些信息
- 所以TCP有了连接的概念，以及连接管理（一条连接的一生=一开始创建+正式使用+销毁）
握手阶段
- 这个阶段就是为了让连接的双方互相同步信息
- 其同步信息也是靠segment这个段来实现，所以也需要来通过应答机制来确实对方是否已经接收
三次握手——建立连接
- 其逻辑上需要四次发送TCP段，但是服务器发给客户端的确认信息和同步信息可以一起发送（减少网络发送的次数，整体提高性能），所以就变成了三次握手
- SYN同步信号SYN==1表示一个连接请求或连接接收报文。
- ACK==1表示是回应信息
- ack就是ASN,seq就是SN,都是占四个字节的大小
- 对于第一次SYN,不能携带数据，因为不一定能连接成功
- 对于第一次SYN和第二次SYN+ACK 因为不一定能连接成功，不能携带数据，如果携带数据，则提升了发送成本，且有可能失败，所以禁止
- 但是第三层次ACK可以携带数据，但不强转
三次握手的状态转换
- 因为只有通过了状态，才能知道每个连接处于何种状态
- 当我们的客户端比如JAVA,我们调用下面的语句，就主动打开从closed关闭变成SYN_SENT的已发送状态
- 服务器是被动打开，从closed变成LISTEN
- 当服务器接收来自客户端的第一次SYN请求，从Listen变成SYN_RCVD(已接收状态)
- 当客户端接收到来自服务器的ACK+SYN,就从SYN_SENT变成ESTABLISHNED(已建立状态)
- 最后当服务接收到来自客户端的ACK,服务器和客户端成功连接，服务器从SYN_RCVD状态变成ESTABLISHNED(已建立状态),然后客户端和服务端建立完成
三次挥手的总结
- 为什么有握手阶段（同步阶段），为了可靠性，确保对方在线&&需要同步给对方一些基本信息，建立其连接
- SYN-----同步信号SYN，是因为synchronized的缩写
- 为什么是三次握手，逻辑上是4次，但是中间服务器的确认回应信号和发送同步信号可以合并为一次发送
- 三次握手的双方：主动连接方和被动连接方
- 三次握手的标志位变化syn/syn+ack/ack
- 三次握手携带数据的情况不能/不能/允许
- 三次握手的SN/ASN变化 a / b a+1/a+1 b+1
挥手阶段
四次挥手
- 四次挥手的第2，3个segment概念上不会合并了，原因是四次挥手的时候，允许一方先挥手，另一方不挥手（就像谈恋爱，允许一方分手，但是在另一方的眼里还是没有分手）
四次挥手的状态变化
特殊情况
- 三次挥手就是将接收方的回应和发出FIN的一同发送
特殊情况的状态变化
关于TIME_WAIT和CLOSE_WAIT
- CLOSE_WAIT是发生在被动方，就相当于对方提出分手，但是我还没有提出分手
- TIME_WAIT是发生在主动方，出现在基本挥手已经结束的情况下
出现的三种种情况
- 当服务器处理了大量的CLOSE_WAIT状态的TCP连接，这种情况是否合理
- 既然挥手的工作已经结束了，为什么还要有一个TIME_WAIT状态而不是直接进入CLOSED状态？
- 服务器上发现了大量的TIME_WAIT状态的TCP连接，是否合理？
第一种情况，合理不合理不确定，因为在我们进行程序设计的时候，会出现比较长时间的单方面关闭情况，此时出现大量的CLOSE_WAIT是合理情况，但是如果没有这种设计，则不合理，可能的原因是我们这一侧忘记调用了调用了socket.close()
第二种情况
- 我们不能确定发送方的最后一次ACK对方一定会接收到，如果对方没有接收到，我们如果直接断开了链接，那再次接收到对面FIN怎么办呢？所以为了避免这种问题，所以我们不能直接释放连接CLOSED
- 我们TCP靠五元组来区分连接，五元组就是一条连接的主键信息，如果我们没有经过TIME_WAIT直接释放，则五元组立即被分配出去了，如果收到了发给了五元组的segment（可能是之前网络传输比较慢的一些数据），那这个数据是给甲还是乙
关于TIME_WAIT的时间设定
- TIME_WAIT的时间是2MSL
- MSL：MAXimum Segment Live：一个Segment能在网络上活着的最大时间
- MSL是个理论值，实际上很多OS取到的经验值，一般修改取一分钟，但是这个值可以修改
- 2*MSL时间过去之后，segment的一个来回肯定是够的 1说明对方一定最后一个ACK(即使对方没有收到，再发送的fin我们也没有收到，说明网络出现问题) 2网络上肯定没有发送给甲的segment了，所以收到的segment一定是给乙的
第三种情况
- 理论上是合理的，但是从标准上来说，没有任何的问题，我们的代码正常的关闭了连接，但实践来说，有些是不合理的，因为维护连接是需要成本的（最主要的硬件成本就是内存），如果让我们的服务器去背负TIME_WAIT的连接成本，相对的压力较大，所以一般让客户端去背负这个维护成本，一般做了网络编程设计的时候，不建议让服务器去主动关闭连接（某些特殊情况下该主动还是主动）
- 客户端上背负的连接比较少，服务器身上的背负的连接很多（几十万——几百万）
应用层和TCP内部看到的内容
TCP的异常情况
- 情况1：在甲的任务管理器里，直接把A进程进程kill（停止）掉，请问，这条连接的命运如何？甲的角度？乙的角度？，
- 情况2点重启电脑，会咋样？点完重启，执行了OS的逻辑，所以，还是关闭所有进程以及它的所有资源，所以正常四次挥手
- 情况3：点击这里关机会咋样（开始页面的关机）? 同理（关机）
- 情况四：直接拨甲的电源（或者长按甲的关机键关机），会怎么样？这种情况下，OS的代码还能执行么？首先甲主机上连接的命运是？（连接只是逻辑的上的概念，表现在实现中，只是内存中一段数据，电都断了，内存中数据还有不，肯定没有了，也就是这个连接就突然之间就消失了，逻辑上说，甲的连接就没了（但是不是正常关闭，也不是异常关闭）），但是乙主机的连接的命运是要看情况讨论：1当下乙的关系保持到原状2看乙有没有可能感知到甲已经不存在了这条信息（1如果乙发生了写事件（乙尝试向甲发数据 收不到确认应答，即使超时重传也收不到，多次尝试之后，乙走异常关闭流程）
TCP的计算
关于命令行如何查看TCP网络状态
- 比如1132进程占用了tcp135端口
- 通过findstr来过滤条件
流量控制
概念
- 广义：TCP发送端会根据对方的接收能力和网络承载能力，动态地条件自己的发送流量（为了提高到达率，从而提高可靠性）
- 狭义：流量控制（Flow Control） 根据对方的接收能力来调节 拥塞控制(Congestion Control)：根据网络的承载能力来调节
如何实现流量控制
- 需要知道对方的接收能力，最好是实时感知到的
- 怎么拿对方的接收能力转换成发送流量
- 拿什么机制来控制发送流量-流量控制
接收能力的获取
- 我们想要知道对方的接收能力，肯定需要对方告诉我们，在Segment header中，我们通过将自己的接收能力通过填写到16位的滑动窗口大小字段中发送给对方
- 怎么做到实时（相对）——所有要发送的segment中都携带该数据
- 即使一段时间没有数据要发送，也要发一个ack+window过去
- 接收窗口=接收缓冲区的大小-已用大小（接收的数据，暂时还没有被应用层读走）
如何转换为发送流量
- 最大发送量（发送窗口）=对方的接收窗口 send_number=f(receive_cap)
通过什么机制来控制发送量——滑动窗口机制
前提讨论
滑动窗口的实例
- 黄色的是滑动窗口的大小 紫色的是已经发送的数据（但是只是发送，不一定响应的了，如果响应了，那么这一块的数据就可以丢弃了） 蓝色的部分是表示应用层发给发送缓冲区的数据，缓冲区只是一个范围的概念，比如第一个图，蓝色的范围应该是0-1500，但是黄色覆盖的意思是（蓝色范围的数据可以从0发到1000）
- 第三个图，滑动窗口的大小应该是900（300-1200）,为什么紫色的也被包含在滑动窗口的范围呢？因为紫色的表示已经发送的数据，但是还没有得到响应，可能在发送的途中，肯定要被当作滑动窗口的一部分，假如现在滑动窗口的大小是500，正在发送的数据是200，那么我们最多只能发300的数据（500-200），因为我们要是发500的数据，当500和200同时到达，就超过对方的接收范围
- 第四个图为什么滑动窗口会继续向右去占用蓝色部分的范围呢？因为我们知道了ASN,说明前面五百的数据已经被接收，肯定不需要再去考虑，就可以抛弃，然后我们知道了对方的接收范围是1000，那么就是从500-1500，500-1800都是应用层发给发送缓冲区的数据（还没有发送的）
总结
- 整个发送缓冲区被看作逻辑上的1未使用的空间2 应用层已写入的数据（目前可发送的（处于滑动窗口内的），暂不可发送的）3目前已经发送的（已发送的未应答的，已发送已应答的）
- 滑动窗口的范围（已发送已应答的，已发送已应答的+最大发送流量）
如何实现拥塞控制
- 作为发送方如何获取当前网络的承载能力
- 发送最大流量(发送窗口)=min(拥塞窗口，接收窗口）
- 如何进行发送流量控制 滑动窗口=（已发送已应答的，已发送已应答+发送窗口）
怎么获取当前网络的承载能力
- 拥塞窗口不像接收窗口，可以让某个角色，发送精确值过来，拥塞窗口实际是一个通过动态算法来实时计算出的结果——估算值
- 既然是算，则算法有很多
- 总的来说，根据丢包率作为重要的因素来推算（丢包率=单位时间内,TCP重发的次数占比）
为什么要面对字节流
字节流给应用层带来的挑战
TCPheader的补充与总结
ASN和SN
大致工作流程
状态转换图
滑动窗口的变化的时机
- 如果没有收到一个较大的ASN,比如5001，就算我们没有收到1001，那也不需要重发1到1000的包
快重传进制
接收窗口信息更新
延迟应答和捎带应答
TCP实现的功能
UDP和TCP的比较
如何选择
- 一般情况下，无脑选则TCP
- 如果不需要可靠性，或者重传的数据对我们的业务没用，典型的例子：微信是视频聊天
- 有时候，嫌TCP做的太麻烦，自己再应用层做可靠性
- 局域网的环境下，网络环境比较好，可能需要广播的需求
如何让UDP变成可靠的
- 就算依照着TCP做的那些功能来实现
基于TCP应用层协议
- HTTP
- HTTPS
- SSH
- Telnet
- FTP
- SMTP
基于UDP的应用层协议
- NFS：网络文件系统
- TFTP：简单文件传输协议
- DHCP：动态主机配置协议
- BOOTP：启动协议（用于无盘设备启动）
DNS：域名解析协议
基于网络层的协议
- 在数据链路层已经实现局域网内部主机到主机可以通信的前提下，实现跨LAN的，主机到主机的通信
IP协议（Internel Protocol）
两种IP地址
- IP地址是网络号+主机号组成
- WAN(广域网)是一个个小的网络（LAN）组成 ，类比中国是由一个个省份组成 xxx(省市 网络号)YYYY(个人信息 主机号) Z(校验码)
IPv4
- 32位的无符号整数（4个字节）,通常用每个字节用十进制表示，中间用.来连接——点分法
IPv6
- 128位组成
将IP地址拆分为网络号和主机号的方法
静态方法
- 静态方法就是提取规定好，了解即可，使用的不多了，因为太浪费IP地址了，比如把A类的10.0.0.0(00001010.0.0.0)分配给比特公司，接近有2^24个IP地址，根本用不完
- 10.138.25.184(00001010.138.25.184) ,其网络号10.0.0.0 主机号0.138.25.184
动态方法
- 在IP地址的前提下，添加了一个网络掩码（newwork mask）
- 网络掩码：无符号的32为整数，特点，前面全是1，后边全是0
如何计算
特殊的IP地址
- 将IP地址中的主机地址全部设为0，就成为了网络号，代表这个局域网；
- 将IP地址中的主机地址全部设为1，就成为了广播地址，用于给同一个链路中相互连接的所有 主机发送数据包；
- 127.*的IP地址用于本机环回（loop back）测试，通常是127.0.0.1 本机环回主要用于本机到本机的网络通信（系统内部为了性能，不会走网络的方式传输）对于开发网络通信的程序（即网络编程）而言，常见的开发方式都是本机到本机的网络通信。
内网地址和公网地址
- 内往外是可以的，但是外往内，不能直接互通，需要中间外网的转播
- 10.0.0.0--10.255.255.255 （10.0.0.0/8）
- 172.16.0.0-172.31.255.255
- 192.168.0.0--192.168.255.255专门给内网使用
- 不同内网的IP重复是没问题的
IP地址的核心功能
- 就是如何将长期目标怎么变成短期目标
- 通过主机内部维护的路由表来完成，只有工作在网络层及以上的设备才能有路由表
- 交换机是没有路由表的
用命令去查看路由表
- 一旦匹配命中，根据网卡得到短期目标（下一跳的地址）
- 在链路上，表示在一个LAN内部，表示长期目标就是短期目标
- 默认网关，就是能搞定就搞，实在搞不定就交给本机的路由器再说（比如出城市，我们不知道去哪，先去火车站再说）
- 192.168.1.0==192.128.1.0这就是匹配成功了，因为在链路上，说明已经进入了当前长期目标的局域网内，所以下一条的IP就是192.168.1.3
IP协议的详解
- 在IP header中，只填写源IP和目标IP，不填写短期目标（下一跳IP），下一跳IP主要是给数据链路层用，，数据链路层有很多的协议，比如比太网，令牌环网，一些无线协议，以太帧来进行数据封装
- 我们经过网络层（IP协议）处理之后，我们根据路由表将长期目标，计算出了短期目标，也就是下一跳的IP，但是我们数据链路层之间的传输需要的是一个mac地址，
如何通过同一个LAN中的IP地址来确定主机(IP->Mac)
- 本地内部通过一张ARP表来进行维护Map<ip,mac>
- 如何动态计算 ，比如利用ARP协议，广播一份ARP请求（将IP地址中的主机地址全部设为1，就成为了广播地址） FF-FF-FF-FF-FF-FF,来向局域网内的所有主机发一份（我的mac地址是，我想中断xxxIP的mac地址），对应的IP地址给出回应
- 静态就是一开始自带的，进入这个局域网就知道了
- 广播域约等于LAN,所以ARN只能在同一个LAN中使用，所以下一跳IP肯定在同一个局域网
应用层的协议
DNS(Domain Name Service)
- 为了解决人类不好记忆IP地址的问题，将一些名字——域名，由DNS来处理成IP地址，比如www.baidu.com
- 这个应用层协议底层默认使用UDP，但是也支持TCP
NAT（Network Address Translation）
- 没有严格的网络层次划分，为了解决内外ip不能上公网的问题，在不同的内网中，IP地址是可以重复的，但是如果都发数据到公网，在公网中IP地址是不可以重复的，这样就出现了问题
- 一般的的家用路由器都会去解决1路由器寻路功能2DNS服务器3NAT(就是将内网的IP地址转换为公网唯一的IP地址，NAT内部记录该关系)
MTU
- 数据链路层对一次能发送的数据大小的现在，对应上层都有影响
- 对于IP表现为分片问题
- 对应TCP，有最大的报文大小 TCP有MSS问题
- 应用层就算尽量少分片，不要超过UDP的最大报文
3485
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
