udp-tcp-ip详解

UDP协议

UDP协议格式:

16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度.
如果16位校验和出错,则数据就直接丢失.

UDP的特点:

无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返 回任何错误信息;
面向数据报: 不能够灵活的控制读写数据的次数和数量,应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;

UDP的缓冲区:
UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续 的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓 冲区满了, 再到达的UDP数据就会被丢弃;

UDP使用注意事项:
我们注意到, UDP协议首部中有一个16位的大长度. 也就是说一个UDP能传输的数据大长度是64K(包含UDP首部). 然而64K在当今的互联网环境下, 是一个非常小的数字. 如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;

基于UDP的应用层协议:
NFS: 网络文件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议

TCP协议

tcp协议全名叫传输控制协议,对数据的传输进行一个详细的控制.
TCP协议格式

源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
32位序号:seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
32位确认号:ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部大长度是15 * 4 = 60
6位标志位:
–URG: 紧急指针是否有效
–ACK: 确认号是否有效 ,ACK=1表示确认号有效，ACK=0表示报文不含确认序号信息
–PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
–RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
–SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段 ,SYN=1表示请求连接
–FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段 ,为1表示关闭本方数据流
16位窗口大小: 数据传输的最大值.
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
16位紧急指针: 标识哪部分数据是紧急数据;

确认应答机制:

TCP将每个字节的数据都进行了编号. 即为序列号.每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发.

超时重传机制:

除了TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个大超时时间.
Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时 间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传.
如果仍然得不到应答, 等待 4500ms 进行重传. 依次类推, 以指数形式递增.
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

连接管理(三次握手,四次挥手):

三次握手
建立TCP连接时，需要客户端和服务器共发送3个包。

第一次：客户端发送初始序号x和syn=1请求标志
第二次：服务器发送请求标志syn，发送确认标志ACK，发送自己的序号seq=y，发送客户端的确认序号ack=x+1
第三次：客户端发送ACK确认号，发送自己的序号seq=x+1，发送对方的确认号ack=y+1

第一次：客户端发送请求到服务器，服务器知道客户端发送，自己接收正常。SYN=1,seq=x
第二次：服务器发给客户端，客户端知道自己发送、接收正常，服务器接收、发送正常。ACK=1,ack=x+1,SYN=1,seq=y
第三次：客户端发给服务器：服务器知道客户端发送，接收正常，自己接收，发送也正常.seq=x+1,ACK=1,ack=y+1

上面分析过程可以看出，握手两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论的。

通俗的说:
1）Client：嘿，李四，是我，听到了吗？
2）Server：我听到了，你能听到我的吗?
3）Client：好的，我们互相都能听到对方的话，我们的通信可以开始了

四次挥手过程

第一次挥手：客户端发出释放FIN=1，自己序列号seq=u，进入FIN-WAIT-1状态
第二次挥手：服务器收到客户端的后，发出ACK=1确认标志和客户端的确认号ack=u+1，自己的序列号seq=v，进入CLOSE-WAIT状态
第三次挥手：客户端收到服务器确认结果后，进入FIN-WAIT-2状态。此时服务器发送释放FIN=1信号，确认标志ACK=1，确认序号ack=u+1，自己序号seq=w，服务器进入LAST-ACK（最后确认态）
第四次挥手：客户端收到回复后，发送确认ACK=1，ack=w+1，自己的seq=u+1，客户端进入TIME-WAIT（时间等待）。客户端经过2个最长报文段寿命后，客户端CLOSE；服务器收到确认后，立刻进入CLOSE状态。

第一次：客户端请求断开FIN,seq=u
第二次：服务器确认客户端的断开请求ACK,ack=u+1,seq=v
第三次：服务器请求断开FIN,seq=w,ACK,ack=u+1
第四次：客户端确认服务器的断开ACK,ack=w+1,seq=u+1

通俗的说:
1）Client：我所有东西都说完了
2）Server：我已经全部听到了，但是等等我，我还没说完
3）Server：好了，我已经说完了
4）Client：好的，那我们的通信结束了

中断连接端可以是Client端，也可以是Server端。
假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，“告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，“告诉Client端，好了，我这边数据发完了，准备好关闭连接了”。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，“就知道可以断开连接了”。Client端等待了2MSL(Max Segment Life, 报文大生存时间)后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

滑动窗口

刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段. 这 样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.

既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间 重叠在一起了).

窗口大小指的是无需等待确认应答而可以继续发送数据的大值. 上图的窗口大小就是4000个字节(四个 段).
发送前四个段的时候, 不需要等待任何ACK, 直接发送;
收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;
只有确认 应答过的数据, 才能从缓冲区删掉;
窗口越大, 则网络的吞吐率就越高;

流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就 会造成丢包, 继而引起丢包重传等等一系列连锁反应. 因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
窗口大小字段越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后, 就会减慢自己的发送速度;
如果接收端缓冲区满了, 就会将窗口置为0;
这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据 段, 使接收端把窗口大小告诉发送端.

拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然 可能引发问题.
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是 很有可能引起雪上加霜的. TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗 口;
像上面这样的拥塞窗口增长速度, 是指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.
为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍. 此处引入一个叫做慢启动的阈值
当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长 当TCP开始启动的时候, 慢启动阈值等于窗口大值;
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;

延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.
假设接收端缓冲区为1M. 一次收到了500K的数据;
如果立刻应答, 返回的窗口就是500K;
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了; 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
一定要记得, 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效 率;
那么所有的包都可以延迟应答么? 肯定也不是;
数量限制: 每隔N个包就应答一次;
时间限制: 超过大延迟时间就应答一次;
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

捎带应答

在延时应答的基础上，我们发现，接受方和发送方都是“一发一收”，所以，我们在发送数据的时候，我们把ACK搭顺风车的方式发送给对方了。

TCP VS UDP对比

可靠传输 vs 不可靠传输
有连接 vs 无连接
字节流 vs 数据报

我们说了TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比 较
TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播;

IP协议

4位版本号(version): 指定IP协议的版本, 对于IPv4来说, 就是4.
4位头部长度(header length): IP头部的长度是多少个32bit, 也就是 length * 4 的字节数. 4bit表示大的 数字是15, 因此IP头部大长度是60字节.
8位服务类型(Type Of Service): 3位优先权字段(已经弃用), 4位TOS字段, 和1位保留字段(必须置为0). 4位 TOS分别表示: 最小延时, 最大吞吐量, 最高可靠性, 最小成本. 这四者相互冲突, 只能选择一个. 对于 ssh/telnet这样的应用程序, 最小延时比较重要; 对于ftp这样的程序, 最大吞吐量比较重要.
16位总长度(total length): IP数据报整体占多少个字节.
16位标识(id): 唯一的标识主机发送的报文. 如果IP报文在数据链路层被分片了, 那么每一个片里面的这个id 都是相同的.
3位标志字段: 第一位保留，第二位置1表示进制分片(报文长度超过MTU，丢弃报文)，第三位更多分片，如果分片了的话, 后一个分片置为1, 其他是0. 类似于一个结束标记.
13位分片偏移(framegament offset): 是分片相对于原始IP报文开始处的偏移. 其实就是在表示当前分片在 原报文中处在哪个位置. 实际偏移的字节数是这个值 * 8 得到的. 因此, 除了后一个报文之外, 其他报文的 长度必须是8的整数倍(否则报文就不连续了).
8位生存时间(Time To Live, TTL): 数据报到达目的地的大报文跳数. 一般是64. 每次经过一个路由, TTL -= 1, 一直减到0还没到达, 那么就丢弃了. 这个字段主要是用来防止出现路由循环
8位协议: 表示上层协议的类型 ,把IP交给TCP还是UDP，其中ICMP是1，TCP是6，UDP是17
16位头部校验和: 使用CRC进行校验, 来鉴别头部是否损坏.
32位源地址和32位目标地址: 表示发送端和接收端.

网段划分

网络号: 保证相互连接的两个网段具有不同的标识;
主机号: 同一网段内, 主机之间具有相同的网络号, 但是必须有不同的主机号;

不同的子网其实就是把网络号相同的主机放到一起.
如果在子网中新增一台主机, 则这台主机的网络号和这个子网的网络号一致, 但是主机号必须不能和子网中 的其他主机重复.
通过合理设置主机号和网络号, 就可以保证在相互连接的网络中, 每台主机的IP地址都不相同. 那么问题来了, 手动管理子网内的IP, 是一个相当麻烦的事情.
有一种技术叫做DHCP, 能够自动的给子网内新增主机节点分配IP地址, 避免了手动管理IP的不便. 一般的路由器都带有DHCP功能. 因此路由器也可以看做一个DHCP服务器.

A类 0.0.0.0到127.255.255.255
B类 128.0.0.0到191.255.255.255
C类 192.0.0.0到223.255.255.255
D类 224.0.0.0到239.255.255.255
E类 240.0.0.0到247.255.255.255

引入一个额外的子网掩码(subnet mask)来区分网络号和主机号;
子网掩码也是一个32位的正整数. 通常用一串 “0” 来结尾;
将IP地址和子网掩码进行 “按位与” 操作, 得到的结果就是网络号;
网络号和主机号的划分与这个IP地址是A类、B类还是C类无关;
通常A类地址的子网掩码为255.0.0.0 B类为255.255.0.0 C类为255.255.255.0

可见,IP地址与子网掩码做与运算可以得到网络号, 主机号从全0到全1就是子网的地址范围; IP地址和子网掩码还有一种更简洁的表示方法,例如140.252.20.68/24,表示IP地址为140.252.20.68, 子网掩码的高24 位是1,也就是255.255.255.0

IP地址的数量限制

我们知道, IP地址(IPv4)是一个4字节32位的正整数. 那么一共只有 2的32次方 个IP地址, 大概是43亿左右. 而TCP/IP协 议规定, 每个主机都需要有一个IP地址.
这意味着, 一共只有43亿台主机能接入网络么?
实际上, 由于一些特殊的IP地址的存在, 数量远不足43亿; 另外IP地址并非是按照主机台数来配置的, 而是每一个网卡都 需要配置一个或多个IP地址. CIDR在一定程度上缓解了IP地址不够用的问题(提高了利用率, 减少了浪费, 但是IP地址的绝对上限并没有增加), 仍然不 是很够用. 这时候有三种方式来解决:
动态分配IP地址: 只给接入网络的设备分配IP地址. 因此同一个MAC地址的设备, 每次接入互联网中, 得到的 IP地址不一定是相同的;
NAT技术(后面会重点介绍);
IPv6: IPv6并不是IPv4的简单升级版. 这是互不相干的两个协议, 彼此并不兼容; IPv6用16字节128位来表示 一个IP地址; 但是目前IPv6还没有普及;

公有IP和私有IP

如果一个组织内部组建局域网,IP地址只用于局域网内的通信,而不直接连到Internet上,理论上 使用任意的IP地址都可 以,但是RFC 1918规定了用于组建局域网的私有IP地址
10.0.0.0-10.255.255.255 前8位是网络号,共16,777,216个地址
172.16.0.0到172.31.255.255前12位是网络号,共1,048,576个地址
192.168.0.0-192.168.255.255,前16位是网络号,共65,536个地址 包含在这个范围中的, 都成为私有IP, 其余的则称为全局IP(或 公网IP);

路由

在复杂的网络结构中, 找出一条通往终点的路线;
IP数据包的传输过程也和问路一样. 当IP数据包, 到达路由器时, 路由器会先查看目的IP; 路由器决定这个数据包是能直接发送给目标主机, 还是需要发送给下一个路由器; 依次反复, 一直到达目标IP地址;

以太网

“以太网” 不是一种具体的网络, 而是一种技术标准; 既包含了数据链路层的内容, 也包含了一些物理层的内 容. 例如: 规定了网络拓扑结构, 访问控制方式, 传输速率等; 例如以太网中的网线必须使用双绞线; 传输速率有10M, 100M, 1000M等; 以太网是当前应用广泛的局域网技术; 和以太网并列的还有令牌环网, 无线LAN等;

以太网帧格式

源地址和目的地址是指网卡的硬件地址(也叫MAC地址), 长度是48位,是在网卡出厂时固化的;
帧协议类型字段有三种值,分别对应IP、ARP、RARP;
帧末尾是CRC校验码

MAC地址:
MAC地址用来识别数据链路层中相连的节点; 长度为48位, 及6个字节. 一般用16进制数字加上冒号的形式来表示(例如: 08:00:27:03:fb:19) 在网卡出厂时就确定了, 不能修改. mac地址通常是唯一的(虚拟机中的mac地址不是真实的mac地址, 可能 会冲突; 也有些网卡支持用户配置mac地址)

MAC地址与IP地址:
IP地址描述的是路途总体的 起点 和 终点;
MAC地址描述的是路途上的每一个区间的起点和终点;

MTU(以太网最大传输单元)以及影响:

对IP协议的影响:
由于数据链路层MTU的限制, 对于较大的IP数据包要进行分包.
将较大的IP包分成多个小包, 并给每个小包打上标签; 每个小包IP协议头的 16位标识(id) 都是相同的;
每个小包的IP协议头的3位标志字段中, 第2位置为0, 表示允许分片, 第3位来表示结束标记(当前是否是后 一个小包, 是的话置为1, 否则置为0); 到达对端时再将这些小包, 会按顺序重组, 拼装到一起返回给传输层; 一旦这些小包中任意一个小包丢失, 接收端的重组就会失败. 但是IP层不会负责重新传输数据;

MTU对UDP协议的影响:
一旦UDP携带的数据超过1472(1500 - 20(IP首部) - 8(UDP首部)), 那么就会在网络层分成多个IP数据报. 这多个IP数据报有任意一个丢失, 都会引起接收端网络层重组失败. 那么这就意味着, 如果UDP数据报在网 络层被分片, 整个数据被丢失的概率就大大增加了.

MTU对于TCP协议的影响:
TCP的一个数据报也不能无限大, 还是受制于MTU. TCP的单个数据报的大消息长度, 称为MSS(Max Segment Size); TCP在建立连接的过程中, 通信双方会进行MSS协商. 理想的情况下, MSS的值正好是在IP不会被分片处理的大长度(这个长度仍然是受制于数据链路层的 MTU). 双方在发送SYN的时候会在TCP头部写入自己能支持的MSS值. 然后双方得知对方的MSS值之后, 选择较小的作为终MSS. MSS的值就是在TCP首部的40字节变长选项中(kind=2);

ARP

IP和MAC映射.使用于主机和路由器中;

源主机发出ARP请求,询问“IP地址是192.168.0.1的主机的硬件地址是多少”, 并将这个请求广播到本地网段 (以太网帧首部的硬件地址填FF:FF:FF:FF:FF:FF表示广播); 目的主机接收到广播的ARP请求,发现其中的IP地址与本机相符,则发送一个ARP应答数据包给源主机,将自 己的硬件地址填写在应答包中;

NAT(网络地址转换协议)

私有IP和公网IP的映射;位于路由器

NAT技术当前解决IP地址不够用的主要手段, 是路由器的一个重要功能;
NAT能够将私有IP对外通信时转为全局IP. 也就是就是一种将私有IP和全局IP相互转化的技术方法:
全局IP要求唯一, 但是私有IP不需要; 在不同的局域网中出现相同的私有IP是完全不影响的;
NAT路由器将源地址从10.0.0.10替换成全局的IP 202.244.174.37;
NAT路由器收到外部的数据时, 又会把目标IP从202.244.174.37替换回10.0.0.10;
在NAT路由器内部, 有一张自动生成的, 用于地址转换的表;
当 10.0.0.10 第一次向 163.221.120.9 发送数据时就会生成表中的映射关系;