哈哈哈哈哈哈哈哈
TCPIP识别一个进行通信的应用需要5大要素
源IP地址目标IP地址源端口目标端口协议号0-1023 知名端口号
1024-49151 这些端口被正式注册了 但是可以用于任何通信
49152-65535 操作系统动态分配的端口号
一些知名端口号如下
20 ftp-data File Transfer [Deafult Data]21 ftp File Transfer [Control]22 ssh23 talent25 smtp Simple Mail Transfer Protocol43 nicname Who Is53 domain Domain Name Server80 http101 hostname NIC Host Name Server443 https
UDP
常被用于以下几个方面
包总量比较少的通信 DNS SNMP等视频 音频等多媒体通信限定于LAN等特定网络中的应用通信广播通信(广播 多播)
TCP
确认应答 序列号
TCP通过检验和 序列号 确认应答 重发控制 连接管理 窗口控制 等 机制实现可靠传输
确认应答ACK acknowledgement
否定确认应答 NACK negative acknowledgement
Q1 发送端发送数据后会等待对端的确认应答
一定时间未等到确认应答 发送端认为数据已经丢失 重发 未收到数据也可能是返回的确认在中途丢失也有可能是对端的确认延迟到达 发送端按照机制重复即可但是对接收端可能重复收到数据 简直就是灾难 需要处理这种情况
A1 需要一种机制 能识别是否已经接收数据 能判断是否需要接收
上述确认应答处理 重发控制 重复控制 等等 功能都可以通过序列号实现 序列号是按顺序给发送数据的每一个字节(8位字节)都标上号码的编号如下图
超时重发
Q1 超时时间如何定义A1 最好找到一个 确认应答一定时间内一定能在这个时间段内返回Q2 TCP要求不论处在何种网络都提供高性能通信 并且无论网络拥堵情况发生何种变化 都必须保持这一特性A2 每次发包时都计算往返时间及其偏差 往返时间和偏差(RTT时间波动的值 方差)相加 超时重发时间就是这个和在大一丢丢的A3 在BSD的Unix以及Windows中超时都是按0.5s为单位 偏差的最小值也是0.5 所以最小的重发时间时1sA4数据被重发之后若还是收不到则再次发送 超时等待时间会2倍 4倍函数延长 数据也不会无限反复的重复 到达一定的次数后如果仍没有任何确认应答 则会判断网络或对端主机异常 强制管理连接并通知应用程序如下图连接管理
三次握手 四次挥手
MSS最大消息长度
TCP在传送大量消息时 是以MSS进行分割 重发也是也MSS为单位
MSS是在三次握手时计算出来的 在发送SYN请求时会在TCP首部写入MSS选项 会在两者中选一个比较小的值投入使用
窗口
为每个数据包进行确认应答的缺点是包往返时间越长网络的吞吐量越差
引入窗口概念 窗口的滑动如下
窗口控制和重发控制如下图P211
流控制
窗口大小这个字段是由接收端控制的 TCP首部中有一个字段通知窗口大小 具体过程如下
拥塞控制P213
通信刚开始就发送大量数据 可能存在隐藏问题
在网络拥堵时 如果突然出现一个较大量的数据可能导致网络瘫痪
TCP为了防止该问题 在通信一开始便会通过一个慢启动算法得出的数值对发送数据量进行控制
定义了一个拥塞窗口的概念
提高网络利用率的规范
Nagle算法 尽在下列任意一种条件满足才能发送数据这个算法可能导致某种程度的延迟因此在窗口系统(X Window System)以及继续控制等领域中使用TCP时往往会关闭该算法的启用已发送的数据全部都已经收到确认应答可以发送最大段长度MSS的数据时 延迟确认应答 每次都立刻回复确认应答的话 可能会返回一个较小的窗口(因为刚接收完数据 缓冲区已满)在流控制一节可以看到接收端可以控制窗口大小延迟机制如下 在没有收到2x最大段长度的数据为止不做确认应答(根据操作系统不同 有时不论数据大小 只要收到两个包就即可返回确认应答的情况) 总而言之就是各种机制延迟确认应答在其他情况下 最大延迟0.5s发送确认应答 很多操作系统设置为0.2s延迟超过0.5时很有可能导致重发数据 这个时间越小 CPU的负荷越高性能也下降 时间越大越有可能触发发送主机的重发处理捎带应答 TCP的确认应答和回执数据一起返回通过一个包发送比如电子邮件协议的SMTP POP 文件传输协议FTP的连接控制部分等没有启动延迟确认应答(即接收数据后立刻返回确认应答)是无法实现捎带应答的因为捎带必须等待应用程序处理完数据并将作为回执的数据返回时才能进行捎带 哈哈哈其他传输层协议P218
UDP-LiteSCTPDCCP等等UDP-Lite
基于UDP的通信中 检验和出现错误 所收到的包将全部丢弃 然而现实中有些应用在面对这种情况不希望丢弃如果将UDP中的检验和设置为无效那么即使数据的一部分毁坏也不会将整个包废弃 不过这个方法并不好 如果是IP首部中的IP地址被破坏或者端口号被破坏等等会产生严重后果为了解决这些问题 UDP-Lite出现了UDP-Lite计算校验和的范围可以由应用自行控制 有这样的机制可以只针对不允许发生错误的部分进行校验和的价差UDP格式
这个没啥好说的
TCP格式
TCP中没有包长度和数据长度的字符串
数据偏移 表示TCP所传输的数据部分应该从TCP包的哪个部分开始计算 可以理解为TCP首部长度控制位 8位大小 每一位都有其意义 P223紧急指针只有在URG控制位为1时有效 P225可选项 P225
