TCP/IP协议
TCP/IP协议栈：
Transmission Control Protocol/Internet Protocol 传输控制协议/因特网互联协议
TCP/IP是一个Protocol Stack，其中包括TCP、IP、UDP、ICMP、RIP、TELNET、FTP、SMTP、ARP等许多协议
网络分层：
- 应用层：对应OSI的应用、表示、会话层
- 传输层： 对应OSI的传输层
- 互联网层： 对应OSI的网络层
- 网络接口层： 对应OSI的数据链路、物理层
通信过程：
可对照OSI模型
TCP/IP和OSI模型的比较
相同点
- 两者都是以协议栈的概念为基础
- 协议栈中的协议彼此相互独立
- 下层对上层提供服务
不同点
- OSI是先有模型；TCP/IP是先有协议，后有模型
- OSI是国际标准，适用于各种协议栈；TCP/IP实际标准，只适用于TCP/IP网络
- 层次数量不同
TCP/CP的传输层（transport）：
tcp、udp协议所在层次
Transmission Control Protocol
TCP特性
- 工作在传输层
- 面向连接协议
- 全双工协议
- 半关闭
- 错误检查
- 将数据打包成段，排序
- 确认机制
- 数据恢复，重传
- 流量控制，滑动窗口
- 拥塞控制，慢启动和拥塞避免算法
- 更多关于tcp的内核参数，可参看man 7 tcp
TCP包头结构：
源端口、目标端口：
计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个,即65536
seq序列号：
表示本报文段所发送数据的第一个字节的编号
在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从0 开始
ack确认号：
表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送方：
我希望你（指发送方）下次发送的数据的第一个字节数据的编号为此确认号
seq为自己，ack为希望对方做的
数据偏移：
表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长
它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远
该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节
URG：
表示本报文段中发送的数据是否包含紧急数据
后面的紧急指针字段（urgent pointer）只有当URG=1时才有效
ACK标志位：
表示是否前面确认号字段是否有效。只有当ACK=1时，前面的确认号字段才有效
TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段
PSH：
提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间
如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中
RST：
复位报文段
如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接，或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段
SYN：
在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报
文段:
当SYN=1，ACK=1时，表示对方同意建立连接
SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段
FIN：
表示通知对方本端要关闭连接了，标记数据是否发送完毕
如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段
窗口大小：
表示现在允许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量，达到此值，需要ACK确认后才能再继续传送后面数据，由Window size value * Window size scaling factor（此值在三次握手阶段TCP选项Window scale协商得到）得出此值
校验和：
提供额外的可靠性
紧急指针：
标记紧急数据在数据字段中的位置
选项部分：
其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：
(2^4-1)*4-20=40字节
TCP协议端口：
传输层通过port号，确定应用层协议，范围0-65535
- 0-1023：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https)
- 1024-49151：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用：1433/tcp(SqlServer)、1521/tcp(oracle)、3306/tcp(mysql)、11211/tcp/udp (memcached)
- 49152-65535：动态或私有端口，客户端随机使用端口，范围定义：/proc/sys/net/ipv4/ip_local_port_range
tcp三次握手：
使用到2个数据报文中的确认号：seq和ack、2个标记位SYN和ACK
seq为代表自己，ack为希望对方做的
握手过程：
- 客户端发起请求，SYN=1，seq=x（随机数）
- server接收确认，发送SYN=1，ACK=1，seq=y（随机数），ack=x+1（期望client的下个seq是原来基础上+1）
- client接收确认，返回ACK=1，seq=x+1（满足期望），ack=y+1（期望server的下个报文是原来基础上+1）
- 前面已经完成了全部连接，开始传数据，后续的报文中，继续根据自己的seq和对方ack确保连接
说人话环节：
只需要两个人都同意了一遍了，后续就只剩约定了和干啥了
- A向B询问说，约会吧？seq=10
- B向A回复说，没问题，希望A几号来。 seq=20，ack=10+1
- A回复B说，没问题，希望B几点钟来。seq=11，ack=20+1
握手状态变化过程：
3步的过程不多不少，2次只能确认client到server能够通信，第三次才能确定server到client能通信
client：
- 初始是closed状态，主动发起请求后（发送SYN=1），立即变成SYN-SENT状态，接收到server的回应后立即变成ESTABLISHED
此时客户端确认了，服务端能够与自己通信
server：
- 初始是closed状态，接收到client的报文后，变成KISTEN状态，回应client后（发送SYN=1)，立即变成SYN-RCVD状态，再次接收到client的报文后立即变成ESTABLISHED状态
此时服务端也确认了，客户端够与自己通信
tcp四次挥手：
使用到2个：seq、ack，2个标记位：FIN、ACK
主动断开放可以是任意一方
挥手过程：
- client发送断开请求，FIN=1，seq=i
- server接收并回复，ACK=1，seq=j，ack=i+1
- server也主动发送一个断开，FIN=1.ACK=1,seq=z，ack=i+1
- client接收并回复，ACK=1，seq=i+1，ack=z+1
状态变化过程：
client：
- 在ESTABLISHED状态发送断开请求后，立即进入FIN-WAIT-1状态，收到server的回复后立即进入FIN-WAIT-2状态，接收到server的主动断开请求后，立即进入TIME-WAIT状态（为了保证数据能安全到达设置的等待时间，考虑到网速的问题，有的快有的慢），在此状态等待2倍的时间，原来是30s，等待60s后进入CLOSED状态
server：
- 在ESTABLISHED状态，接收到client发来的请求，回应给对方后立即进入CLOSE-WAIT状态，自己再主动发起端口请求后，立即进入LAST-ACK状态，收到client的回复后进入CLOSED
有限状态机 FSM:Finite State Machine
tcp在握手挥手时有11种状态变化
| TCP状态 | 含义 |
|---|---|
| CLOSED | 没有任何连接状态 |
| LISTEN | 侦听状态，等待来自远方TCP端口的连接请求 |
| SYN-SENT | 在发送连接请求后，等待对方确认 |
| SYN-RECEIVED | 在收到和发送一个连接请求后，等待对方确认 |
| ESTABLISHED | 代表传输连接建立，双方进入数据传送状态 |
| FIN-WAIT-1 | 主动关闭,主机已发送关闭连接请求，等待对方确认 |
| FIN-WAIT-2 | 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求 |
| TIME-WAIT | 完成双向传输连接关闭，等待所有分组消失 |
| CLOSE-WAIT | 被动关闭,收到对方发来的关闭连接请求，并已确认 |
| LAST-ACK | 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失 |
| CLOSING | 双方同时尝试关闭传输连接，等待对方确认 |
TCP状态转换：
客户端先发送一个FIN给服务端，自己进入FIN_WAIT_1状态，这时等待接收服务端报文，该报文会有三种可能：
- 只有服务端的ACK
只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续2MSL(TCP报文段在网络中的最大生存时间, 建议值是2min).客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失 - 只有服务端的FIN
只有服务端的FIN时，回应一个ACK给服务端，进入CLOSING状态，然后接收到服务端的ACK时，进入TIME_WAIT状态 - 基于服务端的ACK，又有FIN
同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态
TCP/IP连接相关性能优化：
sync半连接和accept全连接队列:
服务器优化重点
半连接：
- client的第一次握手请求，server端会有一个记录队列，客户端发送，服务器回复第一步请求，把着个还未建立的连接记录在队列中，建立完成的自动转到全连接队列
全连接：
- 客户端发送返回报文的时候，也就是三次握手成功时，服务器把连接记录在全连接队列中（把半连接队列中的转到全链接）
内核参数：
| 参数 | 含义 |
|---|---|
| net.ipv4.tcp_max_syn_backlog | 未完成连接队列大小，默认值128,建议调整大小为1024以上 |
| net.core.somaxconn | 完成连接队列大小，默认值128,建议调整大小为1024以上 |
TCP超时重传：
与对方不能建立连接时，tcp协议默认自动进行重试
内核参数：
| 参数 | 含义 |
|---|---|
| net.ipv4.tcp_retries1 | 指定在底层IP接管之前TCP最少执行的重传次数，默认值是3 |
| net.ipv4.tcp_retries2 | 指定连接放弃前TCP最多可以执行的重传次数，默认值15（一般对应13～30min） |
拥塞控制：
概念：
- 网络中的带宽、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可承受的能力，网络的性能就会变坏。此情况称为拥塞
- TCP为提高网络利用率，降低丢包率，并保证网络资源对每条数据流的公平性。即所谓的拥塞控制
TCP拥塞控制的四个部分：
- 慢启动（slow start）
- 拥塞避免（congestion avoidance）
- 快速重传（fast retransmit）
- 快速恢复（fast recovery）
拥塞控制算法在Linux下有多种实现，比如reno算法、vegas算法和cubic算法等。它们或者部分或者全部实现了上述四个部分，当前所使用的拥塞控制算法：
/proc/sys/net/ipv4/tcp_congestion_control
