源端口号（16）								目标端口号（16）
序号（32）
确认号（32）
首部长度（4）	保留（6）	URG	ACK	PSH	RST	SYN	FIN	窗口大小（16）
校验和（16）								紧急指针（16）
选项

源端口号：发送方进程的端口号。

目标端口号：接收端的进程端口号。接收端收到数据后，根据这个端口号来确定把数据送给哪个应用程序的进程

序号：发送端为每个字节进行编号，便于接收端正确重组，保证数据的正确性

确认号：对发送端的确认信息。接收端响应消息时将会用它来告诉发送端这个序号之前的数据段都已经收到，如确认号是x，表示前x-1个数据都已经接收到

首部长度：确定TCP首部数据结构字节的长度。一般字节为20，最长有60个字节

控制位：URG：紧急位。紧急指针有效位

ACK：确认位。只有当ACK=1时，确认序列号才有效；ack=0，确认号字段无效

PSH：急迫位。标志为1时，要求接收方尽快将数据段送达应用层

RST：重置位。rst=1时，要求建立新的链接

SYN：同步位。同步序列号，TCP需要建立连接，syn=1

FIN:断开位。FIN=1时，数据完成传输需要断开连接

窗口大小：本地可接受数据段的数目，这个大小是可以改变的。TCP中的流量控制机制就是依靠这个变化窗口的大小实现的

校验和：用来做差错侦测。字段检验的范围包括首部和数据这两个部分。数据段在发送是和到达目的地是会进行校验和计算，若两次校验和一样，说明数据是正确的，否则会认为该数据已被破坏，接收端将丢弃数据

紧急指针：和URG一起使用才有效（URG=1）

选项：TCP首部可以有多达40字节的可选信息

三.TCP连接

1.三次握手

TCP建立链接的过程为三次握手，TCP是面向连接的，就是说每次发送信息之前都要和对方建立一条可靠的连接。这个过程分三个步骤，成为三次握手。

第一次握手:当客户端（pc1）向服务器（pc2）发送请求连接报文时；会产生SYN-SENT(同步已发送状态）Seq序列号=x（x为随机） SYN=1（表示发送请求连接）

第二次握手：服务器端收到客户端发来的请求报文后，同意建立连接，则向客户端发送确认报文。这时会产生SYN-RCVD(同步收到状态）

Seq=y（服务器也会产生一个序列号，和客户端的序列号不相关）

Ack=x+1（seq序列号x+1，表示确认收到了客户端的请求）

SYN=1（同时也发送一个建立连接的请求）

ACK=1（表示这是条确认请求）

第三次握手：客户端收到服务端确认后，还要向服务器给出确认，然后连接成功建立。这时会有一个已建立连接的状态

seq=x+1（这是客户端的序号为1） avk=y+1（表示收到了服务端的连接请求）

ACK=1（这是确认报文）

1.为什么三次握手不能两次进行连接？

解析：因为三次握手的目的是为了让双方都能够验证各自的发送能力和接受能力。

客户端为A，服务器端B

案例：第一次握手A 发送SYN报文到B，B接收到之后能够确认A的发送能力和自己的接收能力；第二次握手B发送SYN+ACK报文到A，A接收到，能够确认前面发送的SYN被B接收到了，至此A已经确认双方的发送能力和接收能力是好的，因此转为ESTABLISHED(以建立链接）；第三次握手A发送ACK报文到B，B接收后就能够确定了自己的发送能力和A的接收能力是好的。

现在假如A发送的SYN报文没有丢失而是正在网络中某些节点长时间滞留，以至于A认为报文已经丢失，又重新发个SYN报文，B 接收之后和A建立链接，传送完数据之后断开链接。这时前一个滞留的报文到达了B，而B认为A又发来连接请求，若采用两次握手的方法，B会认为传输连接已经建立了，并一直等待A传输数据,而A此时并无连接请求,因此不予理睬,这样就造成了B的资源白白浪费了;但此时若是使用“三次握手”,则B向A返回确认报文段,由于是一个失效的请求,因此A不予理睬,建立连接失败。

2 .TCP断开连接要四次挥手

第一次挥手：客户端发送FIN+ACK报文给服务端，表示自己要断开连接，这个时候客户端已经把数据发送完，没有数据要发送。客户端进入FIN-WAIT(终止等待）状态。

FIN=1 ACK=1

第二次挥手：服务端收到客户端的断开请求，这时候服务端会发送一个用于确定客户请求断开的信息成功接收，有时候这个过程也会和第三次握手进行合并。这时服务端进入了（CLOSE-WAIT)关闭等待状态。

ACK=1

第三次挥手：服务端如果所有的数据已经接收完毕，这个时候会发送一个断开请求，确认这边也没有数据要发送了，需要关闭连接。这时也会产生FIN-WAIT(终止等待）的一个状态

FIN=1 ACK=1

第四次挥手：客户端需要发送一个确定收到了服务端发送的信息，这样一来双方就都关闭了。这时会有一个TIME-WAIT（时间等待），后进入CLOSED,服务端接收到这个确认包之后

ACK=1

1.为什么断开连接是四次挥手不是三次挥手？

四次挥手如下：

第一次挥手：客户端执行主动关闭，发送 FIN报文，表示客户端的数据发送完毕。

第二次挥手：服务端执行被动关闭，发送确认 ACK报文。

第三次挥手：服务端给客户端发送FIN，告诉客户端我也要关闭。

第四次挥手：客户端确认服务端的ACK报文。

因为第一次挥手表示客户端发送了一个FIN报文，表示客户端已发送数据完毕，但是服务端这个时候可能还有数据没有发送完成，先发送给客户端一个ACK报文，等待自己的数据发送完成才能向客户端发送一个FIN报文，表示自己的数据也已发送完成。这样中间就必须用两次来发送ACK和FIN。如果是三次挥手则不能确定服务端的数据是否发送完成，因此会造成主动关闭方的结束报文段长时间未得到响应而进行超时重传等，造成了不必要的资源浪费甚至更意想不到的问题。

半关闭状态：在第四次挥手中有一个半关闭的概念。TCP一方（通常是客户端）可以终止发送数据，但任然可以接收数据

3.TCP连接

通过Sniffer抓包来分析三次握手的过程

四.TCP端口

端口	协议	说明
21	FTP	FTP服务器所开放的控制端口
23	TELNET	用于远程登录，可以远程控制管理目标计算机
25	SMTP	SMTP服务器开放的端口，用于发送邮件
80	HTTP	超文本传输协议
110	POP3	用于邮件的接收