TCP如何保证可靠传输的?
确认机制：保证每个数据包都能收到，
差错检验：保证数据包的正确，
流量控制：保证接收方不会溢出。
顺序编号：保证传输的有序性
1、TCP/IP的可靠传输服务五个特征：面向数据流、虚电路连接、有缓冲的传输、无结构的数据流、全双工的连接。
2、TCP采用了具有重传功能的肯定确认技术作为可靠数据流传输服务的基础。
3、为了提高数据流传输过程的效率，在上述基础上引入滑动窗口协议，它允许发送方在等待一个确认之前可以发送多个分组。滑动窗口协议规定只需重传未被确认的分组，且未被确认的分组数最多为窗口的大小。
4、TCP功能: TCP定义了两台计算机之间进行可靠的传输而交换的数据和确认信息的格式，以及计算机为了确保数据的正确到达而采取的措施。
5、TCP连接使用是一个虚电路连接，连接使用一对端点来标识，端点定义为一对整数（host，port）其中host是主机的IP地址，port是该主机上TCP端口号。
6、TCP使用专门的滑动窗口协议机制来解决传输效率和流量控制这两个问题，TCP采用的滑动窗口机制解决了端到端的流量控制，但并未解决整个网络的拥塞控制。
7、TCP允许随时改变窗口小，通过通告值来说明接收方还能再接收多少数据，通告值增加，发送方扩大发送滑动窗口；通告值减小，发送方缩小发送窗口。
8、TCP的报文格式
报文分为两部分：报头和数据，报头携带了所需要的标识和控制信息。
确认号字段指示本机希望接收下一个字节组的序号；
顺序号字段的值是该报文段流向上的数据流的位置，即发送序号；
确认号指的是与该报文段流向相反方向的数据流。
9、TCP使用6位长的码位来指示报文段的应用目的和内容
URG紧急指针字段可用；ACK确认字段可用；PSH请求急近操作；RST连接复位；SYN同步序号；FIN发送方字节流结束。
10、TCP的三次握手
为了建立一个TCP连接，两个系统需要同步其初始TCP序号ISN。序号用于跟踪通信顺序并确保多个包传输时没有丢失。初始序号是TCP连接建立时的起始编号。
同步是通过交换携带有ISN和1位称为SYN的控制位的数据包来实现的。
握手可由一方发起也可以双方发起。
TCP与UDP的区别：
1.基于连接与无连接
2.对系统资源的要求（TCP较多，UDP少）
3.流模式与数据报模式
4.TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序
连接无连接：
连接（Connection）和无连接（Connectionless）是网络传输中常用的术语，它们的关系可以用一个形象地比喻来说明，就是打电话和写信。
打
电话时，一个人首先必须拨号（发出连接请求），等待对方响应，接听电话（建立了连接）后，才能够相互传递信息。通话完成后，还需要挂断电话（断开连接），
才算完成了整个通话过程。写信则不同，你只需填写好收信人的地址信息，然后将信投入邮局，就算完成了任务。此时，邮局会根据收信人的地址信息，将信件送达
指定目的地。
我们可以看到，这两者之间有很大不同。打电话时，通话双方必须建立一个连接，才能够传递信息。连接也保证了信息传递的可靠性，
因此，面向连接的协议必然是可靠的。无连接就没有这么多讲究，它不管对方是否有响应，是否有回馈，只管将信息发送出去。就像信件一旦进了邮箱，在它到达目
的地之前，你没法追踪这封信的下落；接收者即使收到了信件，也不会通知你信件何时到达。在整个通讯过程中，没有任何保障。因此我们常说，面向无连接的协议
也是不可靠的。当然，邮局会尽力将右键送到目的地，99%的情况信件会安全到达，但在少数情况下也有例外。
面向连接的协议比面向无连接的协
议在可靠性上有着显著的优势，但建立连接前必须等待接收方响应，传输信息过程中必须确认信息是否传到，断开连接时需要发出响应信号等，无形中加大了面向连
接协议的资源开销。具体到TCP和UDP协议来说，除了源端口和目的端口，TCP还包括序号、确认信号、数据偏移、控制标志（通常说的URG、ACK、
PSH、RST、SYN、FIN）、窗口、校验和、紧急指针、选项等信息，UDP则只包含长度和校验和信息。UDP数据报比TCP小许多，这意味着更小的
负载和更有效的使用带宽。许多即时聊天软件采用UDP协议，与此有莫大的关系。
TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。
UDP---
用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的
地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。
用TCP还是UDP，那要看你的程序注重哪一个方面？可靠还是快速？
TCP UDP是两个协议，简单的说，TCP连接要对方确认的，而UDP却不需要对方确认收到包，所以TCP连接更加安全，但是一般播放网络流媒体使用UDP协议
传输层协议一般有TCP和UDP，TCP为可靠传输，协议本身会保证数据传输的可靠，但为此会付出很多额外的网络开销。UDP为不可靠传输，所以传输效率比较高，本端只负责发送数据，不保证对端能否收到。对于UDP，可靠性可以在应用层实现
“流模式”与“数据包模式”在编程的时候有什么区别呢？
1、TCP
打个比方比喻TCP，你家里有个蓄水池，你可以里面倒水，蓄水池上有个龙头，你可以通过龙头将水池里的水放出来，然后用各种各样的容器装（杯子、矿泉水瓶、锅碗瓢盆）接水。
上面的例子中，往水池里倒几次水和接几次水是没有必然联系的，也就是说你可以只倒一次水，然后分10次接完。另外，水池里的水接多少就会少多少；往里面倒多少水，就会增加多少水，但是不能超过水池的容量，多出的水会溢出。
结
合TCP的概念，水池就好比接收缓存，倒水就相当于发送数据，接水就相当于读取数据。好比你通过TCP连接给另一端发送数据，你只调用了一次write，
发送了100个字节，但是对方可以分10次收完，每次10个字节；你也可以调用10次write，每次10个字节，但是对方可以一次就收完。（假设数据都
能到达）但是，你发送的数据量不能大于对方的接收缓存（流量控制），如果你硬是要发送过量数据，则对方的缓存满了就会把多出的数据丢弃。
2、UDP
UDP
和TCP不同，发送端调用了几次write，接收端必须用相同次数的read读完。UPD是基于报文的，在接收的时候，每次最多只能读取一个报文，报文和
报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。也就说，如果不指定MSG_PEEK标志，每次读取操作将消耗一个报文。
3、为什么
其实，这种不同是由TCP和UDP的特性决定的。TCP是面向连接的，也就是说，在连接持续的过程中，socket中收到的数据都是由同一台主机发出的（劫持什么的不考虑），因此，知道保证数据是有序的到达就行了，至于每次读取多少数据自己看着办。
而
UDP是无连接的协议，也就是说，只要知道接收端的IP和端口，且网络是可达的，任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的
数据，则会乱套。比如，主机A向发送了报文P1，主机B发送了报文P2，如果能够读取超过一个报文的数据，那么就会将P1和P2的数据合并在了一起，这样
的数据是没有意义的。
TCP握手协议
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：
未
连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN
包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器
进入ESTABLISHED状态。
Backlog参数：表示未连接队列的最大容纳数目。
SYN-ACK
重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超
过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。
半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。
====================================================================
现在，我们来看一个完整的流程，在一个TCP socket上系统调用connect究竟是如何建立起一个到对端的连接的。我们还是以实验环境172.16.48.2向172.16.48.1的端口5002发起连接请求为例。
第一步，172.16.48.2向172.16.48.1发起连接请求，发送一个SYN段，指明目的端口5002，通告自己的初始序号（ISN，由协议栈
随机产生的一个32位数），设置确认序号为0(因为还没有收到过对端的数据)，通告自己的滑动窗口大小为5840(对端是5792，这似乎有问题，有待进
一步细查)，窗口扩大因子为2(在首部选项中)，通告最大报文段长度为1460(本地局域网)，下面是数据内容(已剥去链路层的以太网首部和网络层的IP
首部)：
数据内容 含义
基本首部
80 0e 源端口(32782)
13 8a 目的端口(5002)
00 00 07 bc 初始序号ISN
00 00 00 00 确认序号
a 首部长度
0 02 标志位，SYN=1
16 d0 滑动窗口大小(5840)
64 9e 校验和
00 00 紧急指针
TCP选项
02 04 05 b4 最大报文段长度(1460)
04 02 允许SACK
08 0a 00 0a 79 14 00 00 00 00 时间戳(0x000a7914)，回显时间戳(0)
01 占位。
03 03 02 窗口扩大因子(2)
第二步，172.16.48.1收到请求包，检查标志位，发现SYN=1，认为这是一个初始化连接的请求，回应这个SYN，同时也发送自己的SYN段(即
ACK,SYN同时置位)。因为SYN本身要占用一个序号（还有标志FIN也要占用一个序号）。所以，确认序号设置为172.16.48.2的ISN加1
(即172.16.48.1期望收到来自172.16.48.2的下一个包的第一个序号为0x07bd。同时也要通告自己的初始序号，滑动窗口大小，窗口
扩大因子，最大报文段长度等，下面是数据内容：
数据内容 含义
基本TCP首部
13 8a 源端口(5002)
80 0e 目的端口(32782)
98 8e 40 91 初始序号ISN
00 00 07 bd 确认序号(对端ISN+1)
a 首部长度
0 12 标志位，ACK=1, SYN=1
16 a0 滑动窗口大小
65 d7 校验和
00 00 紧急指针
TCP选项
02 04 05 b4 最大报文段长度(1460)
04 02 允许SACK
08 0a 00 3c 25 8a 00 0a 79 14 时间戳(0x003c258a)，回显时间戳(000a7914)
01 占位
03 03 02 窗口扩大因子(2)
第三步，172.16.48.2对来自172.16.48.1的SYN段进行确认，至此，TCP三次握手协议完成，连接建立，在172.16.48.2收
到SYN段时，将自己对应的socket的状态由TCP_SYN_SENT改为TCP_ESTABLISHED，进入连接建立状态，下面是数据内容：
数据内容 含义
80 0e 源端口(32782)
13 8a 目的端口(5002)
00 00 07 bd 序号(已不是ISN了)
98 8e 40 92 确认序号（对端ISN+1)
8 首部长度(8*4=32,有12字节的选项)
0 10 标志，ACK=1
05 b4 滑动窗口大小(1460，有问题？待确认)
a5 8a 校验和
00 00 紧急指针
01 占位
01 占位
08 0a 00 0a 79 14 00 3c 25 8a 时间戳(0x0a007914), 回显时间戳(0x003c258a)
=====================================================================
7、简述TCP三次握手过程，并说明为什么要3次握手
TCP 三次握手
TCP 连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。以下步骤概述了通常情况下客户端计算机联系服务器计算机的过程：
1. 客户端向服务器发送一个SYN置位的TCP报文，其中包含连接的初始序列号x和一个窗口大小（表示客户端上用来存储从服务器发送来的传入段的缓冲区的大小）。
2. 服务器收到客户端发送过来的SYN报文后，向客户端发送一个SYN和ACK都置位的TCP报文，其中包含它选择的初始序列号y、对客户端的序列号的确认x+1和一个窗口大小（表示服务器上用来存储从客户端发送来的传入段的缓冲区的大小）。
3. .客户端接收到服务器端返回的SYN+ACK报文后，向服务器端返回一个确认号y+1和序号x+1的ACK报文，一个标准的TCP连接完成。
TCP 使用类似的握手过程来结束连接。这可确保两个主机均能完成传输并确保所有的数据均得以接收
TCP Client Flags TCP Server
1 Send SYN (seq=x) ----SYN---> SYN Received
2 SYN/ACK Received <---SYN/ACK---- Send SYN (seq=y)， ACK (x+1)
3 Send ACK (y+1) ----ACK---> ACK Received， Connection Established
w: ISN (Initial Sequence Number) of the Client
x: ISN of the Server
==========================================================
握手阶段：
序号 方向 seq ack
1 A->B 10000 0
2 B->A 20000 10000+1=10001
3 A->B 10001 20000+1=20001
解释：
1：A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0
2：B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001
3：A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001
数据传输阶段：
序号 方向 seq ack size
23 A->B 40000 70000 1514
24 B->A 70000 40000+1514-54=41460 54
25 A->B 41460 70000+54-54=70000 1514
26 B->A 70000 41460+1514-54=42920 54
解释：
23:B接收到A发来的seq=40000,ack=30000,size=1514的数据包
24:于是B向A也发一个数据包，告诉B，你的上个包我收到了。B的seq就以它收到的数据包的ACK填充，ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议头，IP头，TCP头)，以证实B发过来的数据全收到了。
25:A在收到B发过来的seq为41460的数据包时，一看到41460，正好是它的上个数据包的seq加上包的大小，就明白，上次发送的数据包已安全
到达。于是它再发一个数据包给B。这个正在发送的数据包的seq也以它收到的数据包的ACK填充，ACK就以它收到的数据包的seq(70000)加上包
的size(54)填充,即ack=70000+54-54(全是头长，没数据项)。
26：一样的啊
