TCP协议段信息及作用
在前面我们讲述了UDP协议段的头部信息，UDP协议段信息
那么今天接着说传输层的另一个协议，TCP协议。
TCP是传输层中比较重要的一种协议，它运用的地方很多，比如在FTP协议、http协议中就是运用了TCP的协议，因为它的可靠性，所以很大程度解决了文件传输丢失，或者错误顺序的情况。
我们先来看TCP头部格式
协议画的顺序是从左到右，头部信息也是从左到右进行的。
- 端口号
端口号我们在UDP中已经讲过，我们再来说一下，源端口号为发送主机的某个进程的端口号，目的端口号是发送到远端主机的哪个端口号上。 - 32位序号
在UDP中没有序号，是因为UDP是不可靠传输，那么TCP是可靠传输，就需要对可靠传输做出相对的办法，序号就是其中的一种，给每个发送的数据段打上序号，进行发送，这样就不会出现发送过过去数据错乱问题，这也是确认应答是第一步。初步了解 - 32位确认序号
要想做到可靠传输，那么就要有应答机制，当一个人找一个说话时候，说一会得到那个人的回应就知道那个人听到了，同样的就是这个原理。至于怎么应答，一会说~ - 4位首部长度
首部长度是什么意思，还是4位？首部长度就是TCP协议段中的头部长度，为什么要有4位的首部长度标识字段呢？因为在TCP中头部的长度是可变的，头部存在一个选项，所以是不确定的，那么用4为能标识多大呢？4位表示最大是15，但是我们就不看选项字段，大小已经有20个字节了，那么怎么表示呢？其实是4位表示的数字，数字的每个1都表示4个字节。也就是15 * 4 = 60 那么TCP首部最大为60个字节，最小为20个字节。这样的方式就可以计算出选项的大小，就可以用4位首部的表示数乘4 减去 20 个字节，就是选项的大小。 - 6位保留
保留位就是目前没有用到，所以不作为重点 - 6个标志位
六个标志位，就是上面的ACK、SYN等，我们具体说说每一个标志位的作用
URG：紧急指针是否有效位，这个主要是搭配16位紧急指针而使用，改变数据发送或者接收的优先级
ACK：是当发送端发送数据后，等待接收方回应的标志位，接收方收到，就会回复一个ACK标志位为1的数据报
PSH：当接收端接缓冲区满的时候，发送方在等了一段时间后发现，还是没有把缓冲区的数据取走，这时候，发送方会发送一个PSH标志位为1的数据报来催接收方，快点取走数据
RST：这个标志位主要的作用是在三次握手的过程中，如果三次握手失败，那么RST在就会置为1，请求重新建立连接。稍后详细介绍~
SYN：SYN标志位是用来进行发出建立连接的，我们把带有SYN报文段叫做同步报文段
FIN：在通信进行完成后，需要关闭连接时候的的标志位
在三次握手的过程中，我们来用图来解释一下RST置为1的情况。
三次握手过程
第一握手：当客户端发送SYN请求连接时候，服务器接收SYN信号后，变成SYN_RCVD状态，然后第一次握手完成
第二次握手：服务器给客户端发送一个SYN+ACK表示你发送的请求我已经收到，服务器再向客户端发送请求建立连接信号。客户端收到信号后，进入ESTABLISHED状态。
第三次握手：客户端又给服务器发送ACK，表示已经收到，如果服务器收到ACK这时候，服务器就会进入ESTABLISHED状态，这时才表示建立成功。
RST标志位在第三次握手中起到作用
那么当在第三次握手的过程中，客户端给服务器的ACK丢失，这时候，服务器还未建立连接，但是客户端认为已经建立连接，所以就会给服务器发送数据，当服务器收到数据，但是服务器没有处于ESTABLISHED状态，就会给客户端发送一个RST标志位为1的数据报，表示需要重新建立连接。
试想为什么要这么设计？
如果进行两次握手不是也可以吗？把前两步，把服务器端SYN_RCVED状态改为就绪状态，行不行？
答案是不行。假设有图谋不轨的人要攻击你的服务器，那么他只要不停的给服务器发送SYN请求，而自己却又不发送数据，或者对服务器回应的ACK不理睬，这时候你就需要花费文件描述符来进处理
- 16位窗口大小。
这是为了解决应答机制的效率问题。 - 16位校验和
和UDP相同，都是为了排除数据在传输过程中，出现数据错误的情况。通过校验和来检测数据是否正确 - 16位紧急指针
它也是搭配URG紧急指针是否有效的标志位来进行使用。用来处理优先级高的数据 - 选项
其中就包含了一些对可靠处理，还有一些其它特殊情况的处理信息。 - 数据
从应用层拿来的数据进行添加头部
可靠传输机制的分析
TCP的可靠传输的一个重要的机制就是ACK应答机制，每次在发送数据后要等到
一个应答ACK，来确认收到了数据。
确认应答
在TCP协议段头部有32位序号，与32位确认序号，在主机A发送一个数据报给主机B时，就会给每个消息打上序号，那么在主机B收到数据后，进行排序，然后给主机A发送确认序号为发送数据收到的下一要接收的数据序号。
超时重传
超时重传也是可靠机制的一种，分为两种情况
1）当数据丢失
2）应答ACK丢失
这两个种情况都出现超速重传机制，主机A给主机B发送数据时候，数据在发送过程中丢失，或者是应答是ACK发生丢失，当主机A发送数据后就会启动定时器，在特定的时间间隔中，如果没有收到ACK就会重新发送，那么在如果是数据丢失的情况下，一定时间间隔后就会因为没有收到ACK就会进行重发，但是如果是在主机B收到了数据，ACK在发送的过程中丢失，这时候，主机A给主机B的数据已经收到，再发过去的数据就会用序号来确认是否重复，重复就直接丢掉。
还有一个问题
如何确定超时重传的时间呢？
最好要找出最小的时间，怎么找最小的时间呢？这就要根据自己的网络状况，要保证发送数据后，ACK一定要能返回来，就是要有一个来回的时间，最小不能小于一个来回的时间。如果过小，就会形成频繁的发送重复的包
那么给大点时间行不？要是时间间隔过大就会影响整体的重传效率。
一般在Linux中或者Windows中超时重传的时间为500ms为一个单位，如果再次重发后没有收到就会等待2*500ms 以此等待，到一定的时间就会判断为网络异常，而强行中断。
对于TCP的可靠传输进行了分析，那么为提高效率TCP又做了那些处理？下一篇详细分析
如有错误，还望指正。谢谢~