架构师之路--TCP学习

最新推荐文章于 2023-08-10 15:57:06 发布

shine_du

最新推荐文章于 2023-08-10 15:57:06 发布

阅读量1.9k

点赞数

分类专栏：架构师之路文章标签： tcp/ip 网络网络协议

本文链接：https://blog.csdn.net/weixin_40608446/article/details/121281235

版权

架构师之路专栏收录该内容

59 篇文章 4 订阅

订阅专栏

TCP传输层协议

报头

在这里插入图片描述
我们来分析分析每部分的含义和作用

源端口号/目的端口号: 表示数据从哪个进程来, 到哪个进程去.
32位序号:该序列号被用来跟踪该端发送的数据量
32位确认序号：在接收端则通过确认号用来通知发送端数据成功接收
4位首部长度: 表示该tcp报头有多少个4字节(32个bit)
6位保留: 顾名思义, 先保留着, 以防万一
6位标志位：
URG: 标识紧急指针是否有效
ACK: 标识确认序号是否有效
PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走
RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段
SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段
FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段
16位窗口大小:
16位检验和: 由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分.
16位紧急指针: 用来标识哪部分数据是紧急数据.
选项和数据暂时忽略

三次握手

tcp需要经过三次握手建立连接
第一次:
客户端 - - > 服务器此时服务器知道了客户端要建立连接了
SYN=1,seq=x
第二次:
客户端 < - - 服务器此时客户端知道服务器收到连接请求了
SYN=1,ACK=1,seq=y,ack=x+1
第三次:
客户端 - - > 服务器此时服务器知道客户端收到了自己的回应
ACK=1,seq=x+1,ack=y+1
SYN是同步字段 ACK是确认标识

四次挥手

四次挥手断开链接

客户端 - - > 服务器 FIN=1，seq=u 客户端进入FIN-WAIT-1
客户端 < - - 服务器 ACK=1，seq=v,ack=u+1 服务端就进入了CLOSE-WAIT
客户端 < - - 服务器 FIN=1，ACK=1，seq=w,ack=u+1 客户端就进入FIN-WAIT-2 服务端就进入了 LAST-ACK
客户端 - - > 服务器 ACK=1，seq=u+1,ack=w+1 客户端就进入 TIME-WAIT (2*MSL) 服务器只要收到了客户端发出的确认，立即进入CLOSED状态
第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

TCP 和 UDP 对比

TCP是基于字节流的传输层通信协议，所以TCP编程是基于IO流编程。
客户端：

创建Socket对象，并指定服务器端应用程序的端口号和服务器端主机的IP地址。
使用Socket的对象调用getOutputStream()方法来获取字节输出流对象。
调用字节输出流的write(byte[] buf)或者write(int b)向服务器发送指定数据。
记得关闭流。

服务器端：
5. 创建ServerSocket对象，并指定该应用程序的端口号，端口号必须和客户端指定的端口号一样。
6. 使用ServerSocket对象的accept()方法来监听客户端发送过来的请求，返回值为Socket对象。
7. 调用Socket对象的getInputStream()方法获取字节输入流对象
8. 调用字节输入流对象的read(byte[] buf)或read()方法获取数据。
9. 记得关闭流。

UDP编程
UDP使用数据报进行数据传输，没有客户端与服务器端之分，只有发送方与接收方，两者哪个先启动都不会报错，但是会出现数据丢包现象。发送的内容有字数限制，大小必须限制在64k以内。
发送方：

创建DatagramSocket对象，可以指定应用程序的端口号，也可以不指定。
准备需要发送的数据
创建DatagramPacket对象，用来对发送的数据进行打包，需要指定发送内容. 发送多少. 发送到哪里和接收方的端口号四个参数。
调用DatagramSocket对象的send()方法发送数据。
记得关闭流。

接收方：

创建DatagramSocket对象，指定接收方的端口号，这个必须指定。
创建一个byte类型数组，用来接收发送方发送过来的数据。
创建DatagramPacket对象，准备接收数据。
调用DatagramSocket对象的receive()方法用于接收数据。
使用String类的构造方法将byte类型的数组中的数据转化成String类型并显示。
记得关闭流。

TCP 和 UDP 对比
TCP和UDP之间的优点和缺点, 不能简单绝对地进行比较
TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景
UDP用于对高速传输和实时性要求较高的通信领域
例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播

为什么TCP这么复杂?

因为既要保证可靠性, 同时又要尽可能提高性能.

保证可靠性的机制

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

确认应答机制(ACK机制)
TCP将每个字节的数据都进行了编号, 即为序列号.
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你要从哪里开始发.
比如, 客户端向服务器发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据.
1003, 1004, 1005都没收到.
此时客户端就会从1003开始重发.
超时重传机制
主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B。如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发。但是主机A没收到确认应答也可能是ACK丢失了.
这种情况下, 主机B会收到很多重复数据。那么TCP协议需要识别出哪些包是重复的, 并且把重复的丢弃.
这时候利用前面提到的序列号, 就可以很容易做到去重。
超时时间如何确定? 动态计算 Linux 500ms 2500ms 4500ms 以指数形式递增,累计到一定的重传次数, TCP认为网络异常或者对端主机出现异常, 强制关闭连接
流量控制
TCP支持根据接收端的处理能力, 来决定发送端的发送速度.
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段,
通过ACK通知发送端;
窗口大小越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口大小的通知之后, 就会减慢自己的发送速度;
如果接收端缓冲区满了, 就会将窗口置为0;
这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 让接收端把窗口大小再告诉发送端.
那么接收端如何把窗口大小告诉发送端呢?
我们的TCP首部中, 有一个16位窗口大小字段, 就存放了窗口大小的信息;
16位数字最大表示65536, 那么TCP窗口最大就是65536字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是窗口字段的值左移 M 位(左移一位相当于乘以2).
拥塞控制
如果在刚开始就发送大量的数据, 仍然可能引发一些问题.
因此, TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态以后, 再决定按照多大的速度传输数据.
在此引入一个概念 拥塞窗口
发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口
“慢启动” 只是指初使时慢, 但是增长速度非常快.为了不增长得那么快,
此处引入一个名词叫做 慢启动的阈值, 当拥塞窗口的大小超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长.
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

提高性能的机制

滑动窗口
快速重传 (数据包丢失情况)
延迟应答
捎带应答

滑动窗口
那么我们可不可以一次发送多个数据段呢?
窗口大小指的是无需等待确认应答就可以继续发送数据的最大值.
发送前四个段的时候, 不需要等待任何ACK, 直接发送
收到第一个ACK确认应答后, 窗口向后移动, 继续发送第五六七八段的数据…
因为这个窗口不断向后滑动, 所以叫做滑动窗口.
操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答
只有ACK确认应答过的数据, 才能从缓冲区删掉.
如果出现了丢包, 那么该如何进行重传呢?
1, 数据包已经收到, 但确认应答ACK丢了.
这种情况下, 部分ACK丢失并无大碍, 因为还可以通过后续的ACK来确认对方已经收到了哪些数据包.
2, 数据包丢失
当某一段报文丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001”
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了
因为2001 - 7000接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中.
快速重传这种机制被称为 “高速重发控制” ( 也叫 “快重传” )
延迟应答
延迟应答是为了返回的窗口大小尽量的大
数量限制: 每隔N个包就应答一次
时间限制: 超过最大延迟时间就应答一次
具体的数量N和最大延迟时间, 依操作系统不同也有差异
一般 N 取2, 最大延迟时间取200ms
捎带应答 ACK 搭顺风车

面向字节流

创建一个TCP的socket, 同时在内核中创建一个发送缓冲区和一个接收缓冲区;
调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太大, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太小, 就会先在缓冲区里等待, 等到缓冲区大小差不多了, 或者到了其他合适的时机再发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区,
那么对于这一个连接, 既可以读数据, 也可以写数据, 这个概念叫做全双工
由于缓冲区的存在, 所以TCP程序的读和写不需要一一匹配
例如:
写100个字节的数据, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

粘包问题

首先要明确, 粘包问题中的 “包”, 是指应用层的数据包.
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 字段
但是有一个序号字段.
站在传输层的角度, TCP是一个一个报文传过来的. 按照序号排好序放在缓冲区中.
站在应用层的角度, 看到的只是一串连续的字节数据.
那么应用程序看到了这一连串的字节数据, 就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包.
此时数据之间就没有了边界, 就产生了粘包问题
那么如何避免粘包问题呢?
归根结底就是一句话, 明确两个包之间的边界
对于定长的包

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

TCP 异常情况

进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
机器重启: 和进程终止的情况相同.
机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行 reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
另外, 应用层的某些协议, 也有一些这样的检测机制.
例如HTTP长连接中, 也会定期检测对方的状态.
例如QQ, 在QQ断线之后, 也会定期尝试重新连接.

netstat

netstat的输出结果可以分为两个部分

Active Internet connections 有源TCP连接，其中"Recv-Q"和"Send-Q"指接收队列和发送队列。这些数字一般都应该是0。如果不是则表示软件包正在队列中堆积。这种情况只能在非常少的情况见到。
Active UNIX domain sockets 有源Unix域套接口(和网络套接字一样，但是只能用于本机通信，性能可以提高一倍)。

列名解释：

Proto：显示连接使用的协议。
RefCnt：表示连接到本套接口上的进程号。
Types：显示套接口的类型。
State：显示套接口当前的状态。
Path：表示连接到套接口的其它进程使用的路径名。

netstat常见参数

-a (all) 显示所有选项，默认不显示LISTEN相关。
-t (tcp) 仅显示tcp相关选项。
-u (udp) 仅显示udp相关选项。
-n 拒绝显示别名，能显示数字的全部转化成数字。
-l 仅列出有在 Listen (监听) 的服务状态。
-p 显示建立相关链接的程序名
-r 显示路由信息，路由表
-e 显示扩展信息，例如uid等
-s 按各个协议进行统计
-c 每隔一个固定时间，执行该netstat命令。

LISTEN和LISTENING的状态只有用-a或者-l才能看到

常用netstat相关命令

列出所有端口 #netstat -a
列出所有 tcp 端口 #netstat -at
列出所有 udp 端口 #netstat -au
只显示监听端口 #netstat -l
只列出所有监听 tcp 端口 #netstat -lt
只列出所有监听 udp 端口 #netstat -lu
列出所有监听 UNIX 端口 #netstat -lx
显示所有端口的统计信息 #netstat -s
显示 TCP 或 UDP 端口的统计信息 #netstat -st 或 -su
输出中显示 PID 和进程名称 #netstat -p
netstat 输出中不显示主机，端口和用户名 (host, port or user)
持续输出 netstat 信息 #netstat -c
找出程序运行的端口 #netstat -ap | grep ‘:80’
查看连接某服务端口最多的的IP地址（前20个）
#netstat -nat | grep “10.1.62.23:443” |awk ‘{print $5}’|awk -F: ‘{print $1}’|sort|uniq -c|sort -nr|head -20
TCP各种状态列表
#netstat -nat |awk ‘{print $6}’
统计数量
#netstat -nat |awk ‘{print $6}’|sort|uniq -c
排序
#netstat -nat |awk ‘{print $KaTeX parse error: Expected 'EOF', got '}' at position 2: 6}̲'|sort|uniq -c|\dots$ NF]} END {for(a in S) print a, S[a]}’
直接统计tcp数量监听的数量
#netstat -ant | wc -l

shine_du

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
架构师之路--TCP学习

相关概念OSI参考模型OSI（Open System Interconnect开放式系统互连）参考模型第一层：应用层。定义了用于在网络中进行通信和传输数据的接口；第二层：表示层。定义不同的系统中数据的传输格式，编码和解码规范等；第三层：会话层。管理用户的会话，控制用户间逻辑连接的建立和中断；第四层：传输层。管理着网络中的端到端的数据传输；第五层：网络层。定义网络设备间如何传输数据；第六层：链路层。将上面的网络层的数据包封装成数据帧，便于物理层传输；第七层：物理层。这一层主要就是传输这些二进
复制链接

扫一扫