tcp三次握手实验心得(tcp面向连接三次握手实验)

第一次握手：建立连接时，客户端发送syn包到服务器，并进入SYN_SEND状态，等待服务器确认；SYN：同步序列编号。 第二次握手：服务器收到syn包，必须确认客户的SYN，同时自己也发送一个SYN包，即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
TCP建立的过程中,第一次客户端发送一个序号为j的SYN报文给服务器,服务器收TCP 和UDP不同， 简单说--一个传输数据是可靠，一个传输不可靠 TCP要保证
弄个wireshark 自己ftp一下抓包一看就知道了。
貌似书上都讲的很详细了不过时隔太久，我都忘记了

A、B使用TCP作为传输层传输方式传递数据，流程大致概括如下：A向B打一个招呼，说：你好，我想跟你建立一个tcp的连接，可以吗？B接收到A的招呼，如果愿意建立连接，会说：你好，可以的。A给B发的连接就建立成功了。B在向A回答的时候，也会同时向A提出建立连接的申请（因为TCP是全双工的，双向的）：B会向A说：你好，我也想跟你建立一个TCP的连接，可以吗？A除了之前接收到B给自己的确认，还会接收到B发过来的申请，A收到这个申请后，会向B发出一个确认。这时，B与A的连接也建立成功了。这个过程叫做“TCP三次握手”，当双方都确认建立这个连接之后，就开始传递数据了。。这是一种可靠的传输方式。
syn acksyn 具体查ccna中文教程

在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 Flood攻击）。在这种情况下，形成的是一种半连接状态。服务器会一直等待到计时器超时(30～120秒）后断开半连接。 SYN Flood没有太好的防范方式。

. TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。 如果采用两次的话，会出现下面这种情况。比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机；于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。传完东西后，断开。结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了，这个时候B机就在等待A传东西过去。2. 三次握手改成仅需要两次握手，死锁是可能发生 考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁