不断是长连接，断开再连是短连接
tcp长连接和短连接
TCP在真正的读写操作之前，server与client之间必须建立一个连接，
当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，
连接的建立通过三次握手，释放则需要四次握手，
所以说每个连接的建立都是需要资源消耗和时间消耗的
一、迭代器的优点，为什么使用迭代器？
迭代器能实现for，能取里边的数据，但它里边存的不是生成这个序列的结果，而是生成这个序列的方式，占用空间极小，这就是迭代器的优点
二、三次握手四次挥手目的？
三次握手是为了保证双方都准备好了资源四次挥手是为了保证双方把资源都释放掉了
三、四次挥手的过程是什么？
第一次挥手：
当客户端一旦调用close，你的应用程序虽然看起来没什么效果，但是你的操作系统底层已经发了一个包也就是第一次挥手过去
第二次挥手：
由于你发送的是TCP的数据包，所以才有约定你收到了就必须得马上回一个，出于都遵守协议的友好目的，所以出去就得马上给客户端回一声
第三次挥手：
此时hi客户端他就知道了，刚才第一个发过去的已经真正的收到，由于接到了客户端刚刚的一个包，那么操作系统就会用它的特殊方式底层就会通知recv解阻塞，接阻塞的正常流程z，如果判断里面接收的数据是y有数据的，就可以进行n数据的处理
如果else没有数据了，就可以调用close()，把它关闭掉，一旦调用close，这个操作系统就会有第三次挥手发过去
第四次挥手：
因为客户端有协议，就可以确认已经收到
四、为什么四次挥手，不能把第二次挥手和第三次挥手合并在一起变成三次挥手？
第二次挥手的目的是确认你刚才给我发的包已经收到了 第三次挥手的目标是一个新的请求 因为第一次挥手数据包过来时服务器要有两件事要做 第一件二次挥手的回复 第二件通过应用程序解阻塞之后才能调用close 这个应用程序有可能调用了close 也有可能没调用 只要不调用close 就没有第三次挥手 如果第一次挥手发了数据包之后 服务器是要尽快去认 应用程序里面迟迟不调用close 所以第三次挥手迟迟发不了 如果把二和三合并一起 第三次迟迟发不了 两次挥手都发不了 客户端还等着 所以不能合并 拆开发
五、第三次挥手什么时候发？
调用了close之后才能发
六、为什么客户端先调close()，而服务器不能先调？
1、因为先调close()的一方最终要等2分钟之后才能释放资源，这段期间是不允许用bind的方式重新绑定端口的，就会出现端口被占用的情况
2、而客户端的端口是操作系统随机分配的，被占用之后会再分配一个
3、若服务端先调，则需要设定套接字选项，配置重复利用端口资源才可以
七、在服务器收到第4次z挥手y的数据n包之前，服务器会释放资源吗？
不会，即便服务器调用了close()，仍然会保留资源，保留到客户端发来第4次挥手的数据包到了为止，什么时候到了，什么时候才释放资源
TCP短连接
模拟一种TCP短连接的情况:
1、client 向 server 发起连接请求
2、server 接到请求，双方建立连接
3、client 向 server 发送消息
4、server 回应 client
5、一次读写完成，此时双方任何一个都可以发起 close 操作
在步骤5中，一般都是 client 先发起 close 操作。当然也不排除有特殊的情况。
从上面的描述看，短连接一般只会在 client/server 间传递一次读写操作！
TCP长连接
再模拟一种长连接的情况:
1、client 向 server 发起连接
2、server 接到请求，双方建立连接
3、client 向 server 发送消息
4、server 回应 client
5、一次读写完成，连接不关闭
6、后续读写操作...
7、长时间操作之后client发起关闭请求
建立连接的过程： TCP 连接是通过三次握手进行初始化的。
三次握手的目的是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。
以下步骤概述了通常情况下客户端计算机联系服务器计算机的过程：
1. 客户端向服务器发送一个SYN置位的TCP报文，其中包含连接的初始序列号x和一个窗口大小（表示客户端上用来存储从服务器发送来的传入段的缓冲区的大小）。
2. 服务器收到客户端发送过来的SYN报文后，向客户端发送一个SYN和ACK都置位的TCP报文，其中包含它选择的初始序列号y、对客户端的序列号的确认x+1和一个窗口大小（表示服务器上用来存储从客户端发送来的传入段的缓冲区的大小）。
3. .客户端接收到服务器端返回的SYN+ACK报文后，向服务器端返回一个确认号y+1和序号x+1的ACK报文，一个标准的TCP连接完成。
