1. 面向连接：使用TCP通信的双方必须先建立起连接，然后才能开始数据的读写。建立连接后双方的系统内核会为该连接分配必要的系统资源，用来管理连接的状态和传输在连接上的数据。

2.可靠的：
? ? ? ? ①TCP采用发送应答机制，即发送端发送的每个TCP报文段都必须得到接收方的应答后? 才认为TCP报文段传输成功。序号也保证了传送到接收端实体的包的按序接收。
? ? ? ?

????????②TCP还具有超时重传机制，发送端在发出一个TCP报文段之后启动定时器，若在超时时间范围后还没收到接收端的应答信号，它将重发该数据报文。一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT，加权平均往返时间 RTTs，超时时间 RTO 应该略大于 RTTs。

????????③ TCP报文段最终是以IP数据报发送的，IP数据报到达接收端可能是重复/乱序的。所? 以TCP发送模块还会为每个包指定一个序号， TCP接收模块对接收到的TCP报文段重?排、整理，再交付应用程序。

3.TCP还提供流量控制和拥塞控制，防止过多的数据注入到网路中，缓解压力。

2.2 单播和全双工

????????每条TCP传输连接只能有两个端点，只能进行点对点（一对一）的单播数据传输，以基于广播和多播（目标是多个主机地址）的应用程序不能使用TCP服务。

????????TCP还是一个双向对称的全双工(full-duplex)协议，一个TCP连接存在双向的读写通道，可以使数据在两个方向上同时进行传送操作，在发送数据的同时也能够接收数据，两者同步进行，就像平时打电话一样，说话的同时也能够听到对方的声音。半双工指虽然数据可以在一个信号载体的两个方向上传输，但是不能同时传输，时间段内只有一个动作发生。单工就是说数据传输是单向的，通信双方中，一方固定为发送端，一方则固定为接收端。信息只能沿一个方向传输。

2.3TCP头部

TCP首部的最小长度为20字节，最大为60字节，主要参数如下：

1.??16位TCP源端口(Source Port)：指明发送方应用程序对应的端口。
2.??16位TCP目的端口(Destination port)：定义传输的目的地，即传给哪个上层协议或应用程序。

3.? 32位TCP序列号（Sequence　Number）：简称seq。一次TCP通讯(从TCP连接的建立到断开)整个过程中，一个传输方向上的字节流的每一个报文的编号。例如主机A和主机B进行TCP通讯，A发送给B的第一个TCP报文中，序号值就被系统设置为某个随机值x(ISN, Initial Sequence Number)，在该传输方向(A->B)的后续TCP报文的序号将被系统设置为x加上该报文所携带的第一个字节在整个字节流的偏移。假设某个TCP报文段传输的数据是整个字节流中的第1024~2048字节，那么该报文的seq = x+1025，下一个报文的seq = x+2049。

4.?32位确认序号（Acknowledgment Number）：简称ack。用作对另一方发送来的TCP报文段的响应，其值是收到的TCP报文段的seq序号值加1。
????????假设主机A和主机B进行TCP通信，那么A发送出的TCP报文段不仅携带自己的序号，而且包含对B发送来的TCP报文段的确认号。反之，B发送出的TCP报文段也同时携带自己的序号和对A发送来的报文段的确认号。若确认号为N，则表明到序号N-1为止的所有数据都已正确收到。

对于上面说的seq和ack，简单的说，seq是某一端发送的数据包本身的序列号（两端都有自己的序列号），ack则是确认收到的数据包的seq + 1

5.?4位首部长度（即数据偏移）：标识该TCP首部有多少个32bit字（4字节）。因为4位最大能标识15，所以TCP首部最长是60字节，最短20字节。

6. 6位保留（Reserved）：为了将来定义新的用途所保留，目前这些位都是0。

7. 6位标志位（Code Bits)）：共6个，即URG、ACK、PSH、RST、SYN、FIN：
? ? ? ? 紧急 URG（Urgent）：当 URG =1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据，目前已经很少使用)。?

? ? ? ? 确认 ACK（Acknowledgment）：携带ACK标志的TCP报文段称为确认报文段。ACK = 1时确认号字段有效，这是一个确认的TCP包，取值0则不是确认包。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。

? ? ? ?推送 PSH（Push）：一般是表示发送端缓存中已经没有待发送的数据，提示接收端应用程序应尽快从TCP接收缓冲区读走数据。（若应用程序不读走数据，数据会一直留在TCP模块的接收缓冲区）

? ? ? ? 复位 RST（Reset）：当 RST=1 时，表明TCP连接发生异常或者错误，必须释放连接，再重新建立运输连接

? ? ? ? 同步 SYN（Synchronize）：请求建立一个新的连接，当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1，因此SYN置为1就表示这是一个连接请求或连接接受报文。因此，该标志仅在三次握手建立TCP连接时的前两次有效。

? ? ? ? 终止 FIN（Finish）：释放一个连接。当FIN=1时，表明发送此报文段的发送端的数据已发送完毕，并要求释放连接。

9. 16位窗口大小(Window Size)：TCP流量控制的一个手段。该值用于告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

10. 16位校验和（Checksum）：发送端基于数据内容计算一个数值并填充，接收端要与发送端数值结果完全一样，才能证明数据的有效性。接收端checksum校验失败的时候会直接丢掉这个数据包。CheckSum是根据伪头+TCP头+TCP数据三部分进行计算的。这是TCP可靠传输的一个重要保障。

11. 16位紧急指针（Urgent Pointer）：指向后面是优先数据的字节，在URG标志为1时才有效。存放着一个正的偏移值，该值加上当前报文的序号将得到紧急指针，紧急指针处存放的是紧急数据，是发送端向接收端发送紧急数据的方法。

12. 选项(Option)：长度不定，但长度必须以是32bits的整数倍。这部分最多包含40字节，因为TCP首部最长是60字节（其中还包含前面讨论的20字节的固定部分），常见的选项包括、SACK、Timestamp等等。MSS表示最大分段大小，一个TCP包最大可传输的字节数一般是1500-20-20=1460字节。

需要注意的是：

????????不要将确认序号ack与标志位中的ACK搞混了。
????????确认方ack=发起方seq+1，两端配对。

2.4 TCP三次握手

?2.4.1 三次握手是建立连接的过程

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

????????最开始客户端和服务器都是出于closed状态客户端主动打开closed状态，?tcp服务端进程先创建传输控制块TCB，时刻准备接收客户端的连接请求，此时服务器进入Listen（监听）状态tcp客户进程也是先创建TCB传输控制块，然后主动向服务器发出链接请求报文。

?简单的说，握手过程中主要使用了 TCP 的标志（flag）——SYN（synchronize）和ACK（Acknowledgement)。发送端首先发送一个带 SYN 标志的数据包给对方。接收端收到后，回传一个带有 SYN和ACK 标志的数据包以示传达确认信息。最后，发送端再回传一个带 ACK 标志的数据包，代表“握手”结束。若在握手过程中某个阶段莫名中断，TCP 协议会再次以相同的顺序发送相同的数据包。
?

2.4.2?为什么是三次握手而不是两次? ? ?

第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开多个无效连接。

????????客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器。

????????如果不进行三次握手，而是两次，那么在服务器收到并返回响应之后服务器就会打开连接，此时服务器的响应可能并没有即时送达客户端，导致客户端重发连接请求，导致服务器端收到两个连接。假设每次发送的数据一直在丢失，客户端一直SYN，服务器就会产生多个无效连接，占用资源，这个时候服务器可能会挂掉。这个现象就是我们听过的“SYN的洪水攻击”。

????????如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。
?

?以电影中的桥段来模拟三次握手过程

? ? ? ? 机长（客户端）：成都成都，我是四川8633
? ? ? ? 李现（服务端）：四川8633，请讲
? ? ? ? 机长（客户端）：我现在有点故障，申请下降高度? ? ??

????????1. 当客户端向服务端发起连接时，会先发一包连接请求数据，过去询问一下，能否建立连接，这包数据称为SYN（同步）包（sin包：成都成都，我是四川8633）

只是把SYN开启（将SYN置1）是不够的，报文里还有一个重要字段Sequence序号

PS：为什么还需要sequence序号呢？

????????因为应用程序（客户端）可能连续发送多个序号给服务器（服务端），这样服务器就起码有依据可以判断哪些是累赘信息，而且这个sequence序号是随机生成的，作为初始值来进行后续判断依据，这样就更加保证了通道的唯一性。

? ? ? ? 2. 假设上述例子的序号为8633，当服务器收到SYN以后就要开始响应了，这个时候服务器会在TCP报文中把SYN和ACK（确认）开启（就是全部置为1），SYN? + ACK合起来就是确认同步的意思。那么服务器也生成自己的序号，假设这里自己的序号为：303（随机生成的），这样还不够还要加上确认号，这个确认号就是根据对方的序号+1得到的

? ??????这样客户端在收到号码后-1就知道是不是自己发送的TCP报文了，最后客户端还需要确认，因为如果不确认的话（相当于两次握手），服务器不知道自己发送出去“确认同步”是否被接受。于是必须再发送一次TCP报文来使连接正式建立。

??????3. 这个时候客户端会把ACK开启（ACK置为1），并且序号是服务端确认号（8633+1）,确认号上根据对方的序号+1（303+1）

那么问题来了，每次发来的SYN服务器都要记住它的序号，并且新生成自己需要记住的序号，那服务器就需要挂起非常多的资源，如果有黑客借此不断发送SYN又不进行下一步，就会导致服务器原地崩溃也就是典型的DDoS攻击,因此服务器干脆不保存自己的序号，而是根据服务器的IP地址和端口号等私有信息进行算法的运算得到序号

三次握手之后就建立了连接，这个时候可以发送HTTP请求了?

2.5?TCP四次挥手

全双工TCP通信的每个方向上都有独立的SN(序号），在关闭时，每一个方向都必须单独关闭，这就是四次挥手！假设服务器内容响应完毕了，各自可能就会发起关闭连接的要求了，注意客户端和服务端都能主动发起关闭请求。

客户端接收到服务器端的 FIN 报文并发送确认报文后进入TIME_WAIT状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。最大段生存期，是指报文段在网络中生存的最大时间，超时会被抛弃。

为什么客户端最后要等待2*MSL时间呢？

????????保证客户端发送的最后一个ACK确认报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
等待2MSL是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧连接的请求报文，防止数据包发生混淆。防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。

1.? 假设这里是客户端主动发起关闭请求，这个时候客户端会在报文中同时开始FIN（结束）和ACK两个控制位，这里就是为了结束会话，

因为在发送HTTP请求和响应的时候序号和确认号被不断递增，因此这里就不再用固定数字来表示序号和确认号了

2. 此时一般服务端会先发送一个ACK来进行确认，（然后套路和之前一样，自己的序号用对方的确认号，自己的确认号在对方的序号上+1），

虽然发送了TCP报文，但是此时的客户端并未正式关闭通道，因为服务端那边可能还有需要发送的数据，

3. 等服务端发送完数据以后会再发送一个FIN + ACK 来进行最后的确认，此时序号和确认号不需要改变（因为没有一来一回，只是多了一个控制位FIN来进行确认结束步骤而已）

4. 最后客户端得到最终的结束确认以后，会发送ACK来进行确认。此时自己的序号需要用对方的确认号，确认号是对方的序号+1

? ? ? ? 其实中间的ACK和FIN + ACK两步就足以证明为什么要4次挥手，关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了，但对方还能接收数据，而己方也未必将全部数据都发送给对方了，所以己方收到这个FIN报文之后处于CLOSE-WAIT状态，此时还可以发送一些数据给对方，发送完毕之后再发送FIN报文给对方来表示同意现在关闭连接。

????????而最后还需要客户端一次确认，也是因为需要保证客户端收到了在第二、三次挥手间传递的数据，以及表示收到服务器的FIN请求，完成挥手。
?

2.7?TCP滑动窗口和流量控制

????????窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

????????发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

????????接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能再发送数据。

2.8??TCP拥塞控制

????????在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。

????????因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

????????拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

?3. UDP协议

UDP（User Datagram Protocol）协议全称是用户数据报协议，是无连接协议，也称透明协议，也位于传输层。常见的对讲机、视频会议、VNC等许多都是UDP协议传输

?4?TCP和UDP协议的区别

比如浏览网页，软件聊天，以及收看视频都是通过这两种协议来进行数据传输的

TCP和UDP都工作在传输层，它们的目标都是在程序之间传输数据

而数据可以是文本文件，可以是视频，可以是图片

对于tcp协议和udp协议来说都是一堆二进制数，并没有多大区别。那TCP和UDP之间的区别到底是什么？

最大的区别是一个基于连接（tcp），一个基于非连接（udp）

举个简单的例子：如果把人与人之间的通信比喻成进程与进程的通信，

我们基本有两种方式：第一种方式是写信，第二种是打电话

这两种方式的最大区别是什么：

1. 首先UDP是无连接的，因此减少了开销和发送数据之前的时延

2. UDP使用最大努力交付，即不保证可靠交付

3. UDP是面向报文的，发送方的UDP对应应用程序交下来的报文，添加首部后就向下交付IP层，对应用层交下来的报文，既不合并，也不拆分，而是保留这都些报文的边界，一次交付一个完整的报文?

但是写信（udp）存在以下未知数

1.信寄出去之后对方是否能收到

2.以及收到的信内容是否完整

3.先后寄出去的信，是否按发送顺序接受

4.甚至你填写收信人和收信地址是否存在，你都无法确认

而打电话（tcp）则不同

????????从拨打电话——对方接通——互相通话——结束挂断

????????这一系列流程都能得到及时的反馈，并能确认对方准确的接收到

????????TCP是如何保证以上过程的，有三个关键步骤：三次握手，传输确认，四次挥手

5 字节流和数据报的区别

最简单的解释，TCP的字节流和UDP的数据报，最主要的区别是通信双方是否必须执行相同次数的读、写操作。

TCP实际上也是传输的报文段，这里的“字节流”方式指的是仅把传输中的报文看作是一个字节序列，在字节流服务中，用户进程在某一时刻可以读或写任意数量的字节。由于没有报文边界，发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系，可以类比“水流”，等流动的没有边界的事务，这就是字节流的由来！

因为TCP是面向连接的，并且只能是单播连接，也就是说，在连接持续的过程中，socket中收到的数据都是由同一台主机发出的，因此，知道保证数据是有序的到达就行了，至于读、写数据的次数，每次读写多少数据可以自己看着办。

另外，TCP有一个发送缓冲区和接收缓冲区，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送，如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。比如写100个字节数据时，可以调用一次write写100个字节，也可以调用100次write，每次写一个字节；读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以一次read 100个字节，也可以一次read一个字节，重复100次。

UDP的数据报是网络传输的数据的基本单元，包含一个报头和数据本身，其中报头描述了数据的目的地以及和其它数据之间的关系。在接收的时候，每次最多只能读取一个报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。也就是说发送端调用了几次write，接收端必须用相同次数的read读完。

因为UDP是面向无连接的协议，并且支持广播和多播模式也就是说，只要知道接收端的IP和端口，且网络是可达的，任何主机都可以向接收端发送数据，接收端可以接收来自不同主机的消息。这时候，如果一次能读取超过一个报文的数据，则可能会读取到两个不同来源的混合消息，这样的数据是错误且没有意义的。