Tcp三次握手协议

A--àB

A发送信息到B

B确定后，发送给A

这样A不就可以确定这条链路是通的了，为什么A要再次发送才能确定呢?

这是因为弄错了要确定的主体，真正要确定的是B

B在listen端口等待客户发送链接，B在收到客户确定是要发送数据，才真正的建立链接。只有在得到A确实是要发送链接，B才准备和A建立链接，否则不建立。

第一步

A首先发送sychornize(SYN)想要同步的字节码给B，说：“我想和你建立链接，不知道可不可以啊?”，这个字节只包含A将要发送数据的初始序列号。不带任何数据，只包含了IP头部，和一个tcp头部及可能有的tcp选项。(为什么这样做?)

1、不能确定你要连接的B是否空闲，是否可以提供服务，如果B(服务器，也可以是一台普通的电脑)不存在，或者无法提供服务，那A就不必要再去发送数据。

这样做的原因：

1)节省了网络上带宽。如果所有的链接都是不管三七二十一的把数据发送到另外一台电脑上，这样在所有的链路上都充斥都大量可能没有用的数据，

2)在网络的设计之初，宽带很小，传输的速度也很慢。

第二步

B电脑，如果可以响应，那么就发送一个SYN，表示可以建立连接。这个SYN含有服务器同一连接中发送的数据的初始化序列号。服务器以单个字节向客户发送syn和对客户syn的ACK(表示确认)。

如果B电脑无法提供服务，于A电脑在等待一段时间后自动放弃该连接，或者A可以持续发送“我要连接到B”的请求，直到A确认。

第三步

客户A要确认B电脑的SYN。发送一个ACK到B。服务器B确定A要连接。服务器B等待同一连接上A发送具体的数据。

这里面重点是B要确定A，因为B是为A(C,D,E)提供链接服务的。

这里面有几个问题：

  • 1. 客户数据的初始化序列号，是怎么个生成原则?

  • 2. 同理服务器的初始化序列号，生成原则是什么?

  • 3. 服务器对客户端SYN的ACK是如何生成的?

  • 4. 同理客户端对服务器SYN是如何生成的?

  • 5. 客户端对服务器发送的ACK是如果辨别的?

  • 6. 服务器对客户端发送的ACK是如果辨别的?

解决这些问题首先要明白：

SYN和ACK都是单个字节。

为什么是一个字节，而不是一位比特算了?

因为他要在这8个比特中包含一个IP头部，TCP头部及可能有的TCP选项。

一个字节，8位0---255个十进制数，是很硬件，软件的最小处理单位

硬盘是以最小单位一个字节来读取数据

Mysql的tinyInt,bit也都是单个字节来存储的，我想这和硬盘的最小处理单位有关，而且C语言上的基本数据类型，最小的char也是一个字节，java中的char是两个字节。

SYN和ACK是怎么个回事?

TCP发送数据是按分节发送的，这个分节应该是字节分段发送的意思，一段是一个分节。

每一个分节内的每一个字节都对应一个序列号，这个序列号从1开始递增，到达对端后，重新按序列号进行排序。一个分节最大可以放1024个字节。

但是打招呼时用到的SYN和ACK只用到了一个字节的序列号空间(1-256)，这也就意味着他们的内容数据大小在1-256个字节。而这256个字节只含有一个IP头部，一个TCP头部，和可能的TCP选项。

问题一：IP头部包含什么?

问题二：TCP头部和TCP选项是什么关系?

一个分节最大可以放1024个字节。这一个容量并不固定不变的，受TCP选项中的MSS(Maximum segment size)的控制，可能通过TCP_MAXSEG套接字获取与设置容量。

MSSà用于控制单个分节的容量大小。

TCP选项是对TCP对部的补充，比如说：窗口规模选项，这个功能会随着高速网络和卫星链路，发生改变，以补充TCP头部中通知最大窗口大小为65535.

引出一个问题：窗口规模选项中的窗口是什么，和一个分节传输的大小有何关联?

窗口规模的目的是：提供流量控制

机制是：该窗口在任意时刻都指出接收缓冲区中的可用空间。

应用程序从缓冲区读取数据则窗口变大，缓冲区写入数据则窗口变小。满了，则等待进程读取了数据之后，再接收数据。

进程从硬盘读取数据会有一个层次的缓冲机制，网络连接原来是有缓冲，说就说明，缓冲对于计算机应用程序是一个很好的机制。可以解决性能的问题。

全双工的意思就可以接收数据的同时发送数据(full-duplex)

TCP重要的五点内容：

  1.  面向连接

  2. 提供可靠性

  3.  每个字节数据关联一个序列号，以便排序

  4.  提供流量控制

  5.  连接是全双工

转载于究问社区 ：http://www.ijiuwen.com/blog/937871407235072