如果要想在客户端和服务器端之间传输文件。客户端程序需要确定自己的收发机制是正常的，也需要知道服务器端的收发机制也是正常的，同样，在服务器方面，也是需要自己的收发机制和客户端的收发机制也是正常的。所以三次握手过程就是为了保证双方都能够清楚双方的收发机制是正常的。
首先，客户端向服务器端发出请求，发起第一次握手，发送一个同步信号SYN和一个序列号x，而服务器端正常地收到了这个信息，这时候服务器端可以确定我这边的收信机制和客户端的发信机制是正常的。但是客户端呢？它什么都不能确定，可能它这边除了信号灯是好的，其他的都是垮掉的了。所以需要服务器端回复一个信号，也就是第二次握手。发送一个同步信号，一个ACK确认，证明这是一条确认信号，也有对客户端第一次发过来的的信息的序列号的确认，为x+1，证明序号为x及其之前的信息我都收到了，我需要接收x+1及其后面序号信息，也发送一个自己的序列号。当客户端收到这些信息的时候，客户端能确定什么呢？客户端可以确定我第一次发送的信息服务器已经收到了，要不它也不会回复，所以我的发信机制和服务器端的收信机制都是正常的，而我能够正常接收服务器端发过来的报文，说明我的收信机制和服务器的发信机制也都是正常的。所以到这里，客户端这边就已经确定完毕，它就可以开始发送数据给服务器端了，但是服务器端呢？它还不知道自己的发送机制和客户端的接收机制是否正常，为了让服务器端放心，客户端发出一个确定信号，也就是第三次握手，当服务器端接收到这个信号时，也就可以确定自己的发送机制是正常的，而客户端的接收机制也是正常的了。到这里连接就建立完毕！
而三次握手的必要性主要是为了防止以下两种情况：
1、已过期的连接可能再次传到被连接的主机。假设客户端第一次发送的连接请求发送超时，而客户端会进行第二次的发送，但是此时第一次的发送还是在发送途中的。第二次的连接请求很快就到达服务器端，服务器端也很快的回复确认，这时候连接就建立了。数据传送完毕断开连接后，客户端的第一次连接请求才到达服务器端，服务器端以为又是一次新的请求，就再次发送确认，服务器端就以为是建立了连接，在等待客户端传送数据过来，但是客户端通过序列号和确认号知道这是一次重复确认，就不予理睬，造成服务器傻傻地等待。
2、 死锁可能发生。假定客户端给服务器端发送一个连接请求分组，服务器端收到了这个分组，并发送了确认应答分组。按照两次握手的协定，服务器认为连接已经成功地建立了，可以开始发送数据分组。可是，服务器在客户端的应答分组在传输中被丢失的情况下，客户端将不知道服务器端是否已准备好，不知道服务器端建议什么样的序列号，客户端甚至怀疑服务器端是否收到自己的连接请求分组。在这种情况下，客户端认为连接还未建立成功，将忽略服务器发来的任何数据分组，只等待连接确认应答分组。而服务器端在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
综上所述，第一次握手的目的是建立连接，第二次握手是服务器为了让客户端“安心”，即确认服务器能够并且已经收到消息，第三次握手是客户端为了让服务器“安心”，即确认客户端能够并已经收到消息。至于为什么不是四次，是因为在通信条件正常的情况下，三次握手已经保证了双方连接的正常，四次或更多次偏重的是通信链路故障的情况。