TCP的连接建立
应用程序在通信的时候，也即是进程在通信的时候，浏览器访问web站点，HTTP协议要想发送的话，我这个计算机要先去调用TCP协议，先建立连接，发送tcp建立连接的请求，服务端给我一个确认，我再给服务器一个确认。需要发三个数据包。
建立了TCP连接之后，再发送http的报文，web站点再用这个连接将网页返回给我的客户端。
当所有的通信都结束了，那么浏览器还要释放连接。
tcp在通信之前需要发送3个数据包来建立连接，释放连接需要发送4个数据包。
之前说的可靠传输，流量控制，拥塞避免，这些都是在通信过程当中用到的技术。
建立连接要3次握手，两次握手行不行呢？
客户端要访问服务器的话，客户端向服务端发起建立tcp连接的请求，请求的时候带着一些参数，接受窗口是多少，最大报文段是多少，是不是支持选择性确认，在建立连接请求的时候就带着这些信息。
web服务器收到之后给它一个确认，我的接受窗口是多少，我的报文段最大支持多少，是不是支持选择性确认，将这些参数告诉客户端。
这一次请求，一次确认不就ok了吗？为啥还要求客户端再给服务器再发一个确认。
这里考虑了一种特殊的情况，客户端发送了一个请求，这个请求走的路比较远，这是第一个请求，客户端等了一下发送的请求没有响应，有没有收到确认？于是再发送了一个，这是第二个请求，第二个请求比第一个请求先到，第一个还没到第二个就先到了。
然后web服务器给第二个发了一个确认，然后第一个才到，客户端认为第一个请求作废了，因为没有响应才发送了第二个。
然后web服务器收到了第一个请求之后，它给这个请求发送一个确认，结果客户端一看这是无效的确认，第一个早失效了你给我发确认有啥用？于是就不搭理它了，但是web服务器不知道这个事情，它认为客户端发送了两个建立连接的请求，web服务器这边就会消耗资源。
如果tcp规定了三次握手，web服务器给你发送了确认之后，在一个规定的时间里面没有等到你这个确认，那么web服务器就将这个释放了。
3次握手是为了避免web服务器一直等着客户端的连接，但是客户端不搭理它，为了避免这种情况需要3次握手。
TCP的连接建立
客户端和服务端建立TCP连接的时候，这样的数据包是不带数据的，然后它还有个特点，SYN叫做同步标记位，syn这个标记位为1，ack为确认，确认为0说明，说明tcp首部确认的字段是无效的。
确认通常就是告诉对方收到了第多少个数据包，你该发多少个数据包，因为客户端从来没有收到服务器这边的数据包，所以这个确认号就没有意义，所以这个标记位为0。
参数可以看到最大传输报文段mss 1460。
允许选择性确认。
接受窗口是64240。
上面tcp建立请求包含了上面这些信息，接受窗口是多大，最大报文是多大，是不是支持选择性确认。
上面是首部+选项部分，没有数据部分。
上面是建立连接的请求。
建立TCP连接确认
ack syn标记位为1，说明ack确认标记位起作用了，说明确认字段有意义，可以看到序号为0，确认号为1，告诉客户端1以前的字节都收到了。
下面是服务器的参数。
确认的确认
这是第三个包，ack标志位为1，syn标记位为0了，也就是说只有前面两个数据包请求和确认的syn标记位才为1。
TCP三次握手
来看看客户端和服务端状态。
一开始客户端这里tcp连接是close的，发一个建立tcp连接的请求，syn标记位为1，ack标记位为0，序号是客户端随机给的。
服务器收到之后是listen状态，监听客户端的请求，之后变为syn received状态，之后给客户端发送确认，标记位都为1，y是服务器设定的一个序号，比较大的随机数，确认号为x+1，告诉客户端x收到了，你该发x+1个字节了。
客户端收到确认之后状态为establish建立连接。
之后客户端再给它发确认的确认，ACK大写的代表标记位，小写的代表序号和确认号。
