TCP头部
- 16bit的源端口+16bit的目的端口：告知主机该报文段来自哪里（源端口）以及传给哪个上层协议或应用程序（目的端口）。
- 32bit的序号：一次TCP通信过程中某一个传输方向上的每个字节的编号。序号的值，指本报文段所发送的数据的第一个字节序号。假设主机A和主机B进行TCP通信，A发送给B的第一个TCP报文段中，序号值被系统初始化为某个随机值ISN，那么该传输方向上（A-->B）后续的TCP报文段中的序号值将被系统设置为ISN+该报文段所携带数据的第一个字节在整个字节流中的偏移。
- 32bit的确认号：期待收到对方的下一个报文段的第一个字节的序号。用作对另一方发送来的TCP报文段进行响应。其值是收到的TCP报文段的序号值加1。
- 4bit数据偏移：即首部长度，TCP报文段的起始数据距离TCP报文段的起始处有多远。标识该TCP头部有多少个32bit（4Byte），因为4bit最大能表示15，所以TCP头部最长是60 Byte
6bit保留字段：保留日后用。
6bit标志位：
| 标志名 | 含义 |
| URG紧急标志 | URG=1表示紧急指针有效，告诉系统此报文数据有紧急数据，应该尽快送达。 |
| ACK确认标志 | ACK=1表示确认号有效，一般携带ACK标志的TCP报文段为确认报文段 |
| PSH推送标志 | PSH=1表示提示接收端应用程序应该立即从TCP接受缓冲区中读走数据，为接受后续数据腾出空间。 |
| RST复位标志 | RST=1表示要求对方重新建立连接，一般称携带RST标志的TCP报文段为‘复位报文段’ |
| SYN同步标志 | SYN=1表示这是一个连接请求或连接接受的报文 |
| FIN终止标志 | FIN=1表示通知对方本端要关闭连接了，一般称携带FIN标志的TCP报文段称为“结束报文段” |
5.16bit窗口大小：是TCP流量控制的一个手段，这个窗口是接受通告窗口，它告诉对方本端的TCP接受缓冲区还能容纳多少字节的数据，这样对方就控制发送数据的速度。
6.16bit校验和：由发送端填充。接收端对TCP报文段执行CRC算法，以检验TCP报文段在传输过程中是否损坏。注意，这个检验不仅包括TCP头部，也包括数据部分。是TCP可靠传输的一个重要保障。
7.16bit紧急指针：指出本报文段紧急数据中一共有多少个字节，[ 紧急字段放在最前面 ]。
说明：
- TCP的包没有IP地址，IP地址是IP层上的事，但是有源端口和目的端口。
- 一个TCP连接需要4个元祖（src_ip,src_port,dst_ip,dst_port）来表示是同一个连接，准确地说是五元组【即 协议】，
- 序号用来解决网络包乱序的问题
- ACK确认用来解决不丢包的问题。
- 窗口，即滑动窗口，用于解决流控问题。
TCP状态流转
实际上，网络上的传输时没有连接的，TCP也是一样，所以连接，其实只是通信的双方维护的一个连接状态，让它看上去好像有一个连接一样。
三次握手与四次挥手
TCP的连接可以简单称为三次握手，连接的中止可以称为四次挥手。
三次握手
第一次握手：客户端给服务端发送一个SYN报文，并指明客户端的初始化序列号ISN，客户端处于SYN_SEND状态。
第二次握手：服务端接收到客户端的SYN报文之后，会以自己的SYN报文作为应答，并且指定自己的初始化序列号。同时把客户端的ISN+1作为ack的值，表示自己已经收到了客户端的SYN，此时服务器处于SYN_RCVD的状态。【服务器把这种状态下的请求连接放在一个队列里，称为 半连接队列】
第三次握手：客户端接收到SYN报文之后，会发送一个ACK报文，一样把服务器的ISN+1作为ack的值。
四次挥手
TCP为全双工的连接（可以同时接受和发送），因此关闭连接的时候，必须要关闭传和送两个方向的连接。
客户端给服务器发送一个FIN的TCP报文，然后服务器返回给客户端一个确认ACK报文，并且发送一个FIN报文，当客户机回复ACK报文，连接就结束了。
为什么是3次握手以及4次挥手？
1.进行三次握手的主要作用：为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。
实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息，确保数据是按序到达的，同时也能防止SYN泛洪等Dos攻击。
为了维持可靠数据传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到序列号起始值的必经步骤，如果只有两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认。
2.进行三次握手的主要作用，4次挥手其实是两次，因为TCP是全双工的，所以发送方和接受方都需要FIN和ACK，只不过有一方是被动的，所以看上去是4次挥手，如果两边同时断连接，那寄回进入到CLOSINF状态，然后到达TIME_WAIT状态。
SYN攻击：
Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直到超时。这些伪造的SYN包将长时间占据半连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至瘫痪。SYN攻击是一种典型的DoS、DDos攻击。
防御SYN攻击的方式：
- 缩短超时时间（SYN timeOut）
- 增加最大半连接数
- 过滤网关防护
- SYN Cookie技术
针对SYN泛洪问题，服务器必须要有能力可以识别出请求连接报文的真假性：凡是能够接收到第二个TCP握手报文，并发出第三个握手报文的机器，应该就是真实IP，否则就是伪IP。具体措施即 只要服务器在第二个握手报文里嵌入一个‘Opaque Cookie’，凡是第三个报文里携带这个‘Opaque Cookie’的，满足上述条件，就可判为真实Ip，否则为伪造Ip。
OpaqueCookie不透明Cookie，只有服务器才能理解，服务器可以加密，避免被伪造。Cookie里包含有连接的TCP四元组，时间戳等关键信息，然后加密成为一个字符串。这样服务器不需要保存任何对方的状态，自然不需要动态分配内存，服务器完全是无状态的。
一旦第三个握手报文到来时，通过解密得到关键字段，判定为非伪造Cookie，非伪造源Ip，是合法的TCP连接，服务器立马分配内存，保存TCP连接的所有状态信息，保护内存防止被滥用。
可靠传输
在网络异常（丢数据包| 丢ACK包 或者超时）的情况下，TCP如何控制数据传输以保证可靠传输？
超时重传
TCP每发送一个报文段，就对这个报文段设置一个计时器。只要计时器设置的重传时间到了，但是还没有收到确认，就要重传这一报文段。
利用LInux上的命令‘ tcpdump-ieht0 'port 9001' ’,可以抓取网卡eth0上的9001端口上的包。 按Crtl+c结束tcpdump命令。
RTO: 重传超时时间 RetransmissionTimeOut ：指发送端发送数据后，重传数据前等待接收方收到该数据报报文的ACK时间。
RTO太长，重发就慢了，效率低，RTO太短，重发就快了可能会增加网络拥塞，导致更多超时，从而引发更多重发。
因为网络传输状况不可预知，收发两方具有时延差异，为恰当设置RTO，TCP协议采用自适应算法，以适应互联网分组传输时延的变化。这种算法的基本要点是TCP监视每个连接的性能，由每一个TCP的连接情况推算出合适的RTO值，当连接时延性能发生变化时，TCP也能相应地自动修改RTO的设定，以适应网络的变化。
为了动态设置RTO，TCP引入RTT【Round Trip Time：连接往返时间 ,指的是 发送端从发送TCP包开始到接受它的立即响应所耗费的传输时间 】。
对于一个连接而言，若能有了解端点见的RTT，则可根据RTT来设置一个合适的RTO。显然，在任何时刻，连接的RTT都是随机的。TCP通过测量来获得当前连接的一个估计值，并以该RTT估计值为基准来设置当前的RTO，自适应算法的关键就在于对当前RTT的准确估计，以适时调整RTO。
滑动窗口
TCP的滑动窗口主要有两个作用：1，提供TCP的可靠性。 2，提供TCP的流量控制。同时滑动窗口也体现了TCP面向字节流的设计思路。
TCP的窗口是一个16bit的字段，它代表窗口的字节容量，也就是TCP的标准窗口最大为个字节。另外在TCP的选项字段还包含一个TCP窗口扩大因子，option-kind=3，option-length=3,option-data取值范围为0~14,窗口扩大因子可以用来扩大TCP窗口，可把原来16bit的窗口，扩大为32bit。
对于TCP会话的发送方，任何时候在其发送缓存内的数据都可以分为4类。①已经发送并且得到对方ACK ；② 已经发送但未收到对方ACK ； ③ 未发送但是对方允许发送 ；④ 未发送且对端不允许发送 。其中②和③两部分数据称之为发送窗口。如图
当收到接收方发送 新的ACK对于发送窗口中后续字节的确认时，滑动窗口原理如下图：
对于TCP的接收方，在某一个时在它的接收缓存内存在三种状态，①已接收 ②未接受准备接受 ③ 未接受且未准备接受。【由于ACK有TCP协议栈直接恢复，所以不存在‘已接收未回复ACK’的情况 】。其中②称为接受窗口。
由于TCP是全双工的协议，会话双方可以同时接受和发送数据。TCP会话的双方各自维护了一个‘发送窗口’和‘接收窗口’，其中各自的接受窗口取决于应用，系统，硬件的限制。各自的发送窗口则取决于对方通告的‘接收窗口’
累积确认
滑动窗口实现面向流的可靠性来源于‘确认重传’机制，TCP的滑动窗口的可靠性也是建立在‘确认重传’的基础上的，发送窗口只有接受到对方对于本段发送窗口内自己的ACK确认，才会移动发送窗口的左边界。接受窗口只有在前面所有的段都确认的情况下才会移动左边界。在前面还有字节未接受但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对方会对这些数据重传。
TCP的滑动窗口是动态变化的。
拥塞控制
慢开始+拥塞避免
发送方维护一个拥塞窗口cwnd，根据网络拥塞程度进行动态变化。只要网络不出现拥塞，拥塞窗口就增大一些，如果出现了拥塞，拥塞窗口就减少一些。
只要发生了超时重传，就判断出现了网络拥塞。
发送方将拥塞窗口作为发送窗口swnd，即cwnd=swnd
发送方一开始维护一个慢开始门限ssthresh：
- 当cwnd<ssthresh时，就采用慢开始算法。
- 当cwnd>ssthresh时，就采用拥塞避免算法。
- 当cwnd=ssthresh时，两种算法中选一个即可。
慢开始指的是[当cwnd<ssthresh] 一开始cwnd的值小，向网络中发送的数据包少，但是是cwnd的值指数增长。每收到一个报文段的ACK就将cwnd的值+1。当 [ cwnd>ssthresh ]时，采用拥塞避免算法，cwnd的值线性增长。发生重传时，将sstresh=cwnd/2，cwnd=1，将拥塞避免算法切换到慢开始算法。
快重传+快恢复
慢开始+拥塞避免是1988年提出的TCP拥塞控制算法，1990年又增加了两个新的拥塞控制算法，改进了TCP的性能。
有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。这样也会导致发送超时重传，误认为网络拥塞了，发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。
所谓的快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
要求接收方不要等到自己发送数据时才进行捎带确认，而是要立即发送.
即使收到了失序的报文，也要立即对已收到的报文段的重复确认。
发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞(进而降低拥塞窗口cwnd为1)，使用快重传可以使整个网络的吞吐率提高约20%。
发送方一旦收到3个重复确认，就知道只是丢失了个别的报文段，于是不启动慢开始算法，而是执行快恢复算法；
发送方将慢开始门限ssthresh值和拥塞窗口值调整为当前窗口的一半，开始执行拥塞避免算法。
也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh+3，既然发送方收到3个重复确认，就表明有3个数据报文段已经离开了网络。这3个数据报文段不再消耗网络资源而是停留在接受方的接受缓存中，可见现在网络中不是
流量控制
简介: 让发送方的发送速率不要太快，防止接收方接受窗口溢出产生丢包。既要让接收方来得及接收，也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。
实现方式1：停止-等待方式
发送方每发送一帧。都必须停止发送，等待接收方发回的针对改帧的确认，之后才能发送下一帧。
【效率低】 接收方每接受一帧，都要给对方发回一个确认，表示可接受下一帧。
实现方式2：滑动窗口流量控制。
TCB连接建立后，B告诉A，B的接受窗口。主机A根据这个值设置自己的发送窗口。
发送方的大小Wt 表示在未收到接收方发来确认的情况下，最多还可发送多少帧。
接收方维护一个接受窗口。只有当接收到的序号落入接受窗口内才收下该桢。将接收窗口向前滑动一位，并给发送方发送一个确认。若接收到帧序号落在接受窗口之外，一律丢掉。
死锁问题：引入持续计时器
假设【 B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。
但这个报文段在传送过程中丢失了。A 一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。A 如果没有其他措施，这种互相等待的死锁局面将一直延续下去。】-->--为了解决这个问题，TCP 为每一个连接设有个持续计时器。
只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。
若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。
若窗口不是零，则死锁的打破僵局。
数据发送时机
可以用不同的机制来控制 TCP 报文段的发送时机:
第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push)操作。
第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。
TCP协议存在的主要安全威胁
- SYN泛洪攻击
- ACK泛洪攻击
- Land攻击
- 序列号预测攻击
UDP协议
特点
- 无连接的协议：传输数据之前，源端口和目的端口无需建立连接。
- 不可靠的协议：如果在重发送方到接收方的传递过程中出现数据报的丢失，协议本身并不能做出任何检查或提示
UDP协议存在的安全威胁
- 假冒攻击
- 泛洪攻击
- 劫持攻击
312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
