【JavaWeb学习笔记】TCP/IP 协议(二)

TCP/IP 协议(一)

TCP八大特性

TCP/IP 协议(二)

 

2.3 TCP 协议

面向字节流

创建一个 TCP 的 socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区

 

• 调用write时, 数据会先写入发送缓冲区中;
• 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
• 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
• 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
• 然后应用程序可以调用read从接收缓冲区拿数据;
• 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

由于缓冲区的存在 , TCP 程序的读和写不需要一一匹配 , 例如 :

 

• 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
• 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

粘包问题

• 首先要明确, 粘包问题中的 "包" , 是指的应用层的数据包.
• 在TCP的协议头中, 没有如同UDP一样的 "报文长度" 这样的字段, 但是有一个序号这样的字段.
• 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
• 站在应用层的角度, 看到的只是一串连续的字节数据.
• 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包

那么如何避免粘包问题呢 ? 归根结底就是一句话 , 明确两个包之间的边界 .

 

1.  以 \n 作为明确的边界（应用范围更广）
2. 以固定大小作为流边界

 

• 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
• 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);

思考 : 对于 UDP 协议来说 , 是否也存在 " 粘包问题 " 呢 ?

 

• 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界.
• 站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况.

TCP异常情况

进程终止 : 进程终止会释放文件描述符 , 仍然可以发送 FIN. 和正常关闭没有什么区别 .

 

机器重启 : 和进程终止的情况相同 .

 

机器掉电 / 网线断开 : 接收端认为连接还在 , 一旦接收端有写入操作 , 接收端发现连接已经不在了 , 就会进行reset. 即使没有写入操作 , TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在,也会把连接释放.

 

另外 , 应用层的某些协议 , 也有一些这样的检测机制 . 例如 HTTP 长连接中 , 也会定期检测对方的状态 . 例如QQ, 在 QQ 断线之后 , 也会定期尝试重新连接

 

TCP异常情况处理机制

1. 可挽救：电脑重启或者结束进程的时候，他会发送最后一次FIN请求，和正常关闭TCP没有什么区别
2. 不可挽救：电脑断电/网线突然中断时，TCP保活定时器会定时检测对方是否在线，如果检测的结果是没有任何响应，说明已经掉线，立即释放连接。

TCP小结

为什么 TCP 这么复杂 ? 因为要保证可靠性 , 同时又尽可能的提高性能 .

 

可靠性:

• 校验和
• 序列号(按序到达)
• 确认应答
• 超时重发
• 连接管理
• 流量控制
• 拥塞控制

提高性能:

• 滑动窗口
• 快速重传
• 延迟应答
• 捎带应答

 基于TCP应用层协议

• HTTP
• HTTPS
• SSH
• Telnet
• FTP
• SMTP 

TCP/UDP对比

• TCP是面向连接的，UDP是无连接的
• TCP是可靠的，UDP是不可靠的
• TCP是面向字节流的，UDP是面向数据报文的
• TCP只支持点对点通信，UDP支持一对一，一对多，多对多
• TCP报文首部20个字节，UDP首部8个字节
• TCP有拥塞控制机制，UDP没有
• TCP协议下双方发送接受缓冲区都有，UDP并无实际意义上的发送缓冲区，但是存在接受缓冲区
• 对某些实时性要求比较高的情况，选择UDP，比如游戏，媒体通信，实时视频流（直播），即使出现传输错误也可以容忍；其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失

 

用UDP实现可靠传输？

参考 TCP 的可靠性机制 , 在应用层实现类似的逻辑 ;

 

• 引入序列号, 保证数据顺序;
• 引入确认应答, 确保对端收到了数据;
• 引入超时重传, 如果隔一段时间没有应答, 就重发数据;
• ......

3.网络层

在复杂的网络环境中确定一个合适的路径.

 

 

3.1 IP 协议

基本概念

主机: 配有IP地址, 但是不进行路由控制的设备;

路由器: 即配有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, IP模块就会丢弃报文. 第三位表示"更多分片", 如果分片了的话, 最后一个分片置为1, 其他是0. 类似于一个结束标记.
• 13位分片偏移(framegament offset): 是分片相对于原始IP报文开始处的偏移. 其实就是在表示当前分片在原报文中处在哪个位置. 实际偏移的字节数是这个值 * 8 得到的. 因此, 除了最后一个报文之外, 其他报文的长度必须是8的整数倍(否则报文就不连续了).
• 8位生存时间(Time To Live, TTL): 数据报到达目的地的最大报文跳数. 一般是64. 每次经过一个路由, TTL -= 1, 一直减到0还没到达, 那么就丢弃了. 这个字段主要是用来防止出现路由循环
• 8位协议: 表示上层协议的类型
• 16位头部校验和: 使用CRC进行校验, 来鉴别头部是否损坏.
• 32位源地址和32位目标地址: 表示发送端和接收端.
• 选项字段(不定长, 最多40字节)