一：前情概述
应用层数据报文到传输层时，若采用TCP协议则会在其报文头部添加TCP报文头，同理当服务端接收到数据报文解析到传输层时也会根据TCP报文头进行相应的逻辑处理。TCP首部蕴藏大量协议数据信息，学习TCP必须抽丝剥茧将其吃透
二：端口Port
Wireshark抓包显示在TCP首部前两个字段就是源端口与目的端口，端口号为什么要在传输层协议中携带？真相只有一个，定位！！网络数据包如何确定归属，服务器部署N个应用，依靠的就是端口号。开发部署过程中都知道应用需要暴露监听端口，且该端口必须唯一不能复用，不然就是Address Already used！
2.1 端口常识
一台主机最多可以有65535个端口，一般也不会用到这么多。其中部分端口由IANA机构统一管理，这类端口称之为熟知端口，范围是0 ~ 1023。比如HTTP默认的80、HTTPS默认的443、SSH默认的22等等。
当然，除去0~1023范围的熟知端口，还有部分不受IANA控制，但是会由IANA登记使用情况的端口，这类端口称之为已登记端口，范围是1024 ~ 65535 * 0.75 - 1 = 49151。比如Redis的6379、MySQL的3306、ZK的2181等等
除了上述两类端口之外剩余的端口都是临时端口号，这些端口供本地应用临时分配端口使用。当然这个范围也是可以控制的，控制变量为
/proc/sys/net/ipv4/ip_local_port_range
2.2 Linux端口操作
通过netstat、lsof等命令加上端口可以查看对应的应用程序PID，当然也可以使用nc、telnet检查远程主机端口使用情况等信息
三：序列号Sequence Number
上一篇文章中就已经接触到序列号的概念，一个完整的应用层报文会因为诸多限制(后续讲解)切割划分为多个数据包进行传输，传输过程中因为网络延迟波动等因素导致数据包顺序会出现混乱。数据接收方怎么按照顺序重组数据包？答案就是依靠序列号！总结起来序列号作用如下：
根据序列号确定数据包顺序,解决数据分包后因为网络波动延迟导致的数据包乱序问题
四：确认号ACK
定时重传也是保证TCP安全可靠的一个重要手段，上一章节讲到网络分包，既然一个完整的数据应用包可能会因为限制切分为多个数据包，那么有些数据包就有可能丢失。一千个包丢了一个需要将一千个包重传？显然是愚蠢的设计！针对上述情况提出确认号概念，ACK在上一篇文章中也已经涉及。其具体作用含义如下：
比确认号小的包都已经接收到了，下次传输请使用确认号作为序列号传输
五：标记Flags
| 标签 | 作用 |
|---|---|
| ACK | 标识为确认包 |
| PSH | 标识立即交给应用层，不能进行缓存 |
| RST | 标识强制断开连接，包不合法、连接已经断开、无法处理的包 |
| SYN | 标识连接建立 |
| FIN | 标识连接断开 |
六：校验和Checksum
数据包经历千辛万苦总算到达数据接收方，必须经过灵魂两问：是否还完整？有被篡改么？机器语言就是数据的交流，出发的时候发送端就给这个数据包标记好，有N数量的数据，当接收端收到数据包后就会校验计算