tcp服务器客户端(python tcp服务器)

服务器初始化 (1)调用socket,建立文件描述符(2)调用bind,将文件描述符与ip/port链接起来。若端口号已被占用，则bind失败(3)调用listen，声明该文件描述符是服务器的一个文件描述符，为以后的accept作准备(4)调用accept,并处于阻塞状态，等待客户端链接创建链接(1)调用socket，建立文件描述符(2)调用connect，向服务器发起链接请求。(3)connect会发送一个请求SYN段并阻塞等待服务器应答(第一次)(4)服务器收到SYN，会给客户端发送一个确认应答的同时发送一个请求(SYN+ACK)，表示赞成创建链接(第二次)(5)客户端收到客户端发的SYN+ACK段，代表客户端链接已创建成功，进入ESTABLISHED状态，从connect()。客户端再向服务器发送一个ACK段，服务器收到后则服务器端链接也创建成功，服务器也进入ESTABLISHED状态。a98328b87f4c48d3b44670f231eaa59a.gif数据传输(1)链接创建成功后，在同一链接、同一时刻，通讯双方可同时写数据(全双工)(2)服务器端从accept()返回后调用read()开始读数据，若没有数据则阻塞等待(3)客户端调用write()向服务器发送数据请求，客户端收到以后调用read()处理请求，此过程服务器调用read()阻塞等待(4)服务器调用write()将处理好的请求发送给客户端，再次调用read()等待下一个请求(5)客户端收到后从read()返回，发送下一条请求，如此循环下去web断开链接(1)没有数据处理了，则客户端调用close()关闭链接，给服务器端发送一个断开链接请求FIN段(第一次)(2)服务器收到客户端的FIN段，给客户端发送一个确认应答ACK段代表赞成断开链接，客户端收到ACK段并调用read()返回0，代表客户端链接已断开(第二次)(3)read()返回0以后，服务器知道客户端已断开链接，它也调用close()关闭链接，给客户端发送一个断开链接请求FIN段(第三次)(4)客户端接收到服务器端发送的FIN段，给服务器一个确认应答ACK段，代表赞成断开链接。客户端进入TIME_WAIT状态，服务器收到客户端的ACK后则服务器断开链接。a98328b87f4c48d3b44670f231eaa59a.gif 服务器总结：1.为何是三次握手而不是两次或四次握手？(1)若是是两次握手，则客户端发送链接请求SYN，服务器端接收链接请求并给客户端发送一个ACK进入ESTABLISHED状态，服务器端认为链接创建成功。有可能服务器端发送的ACK在传输过程当中丢了，客户端没有收到ACK从而认为链接没有创建成功。客户端认为链接没有创建成功则会不停的发送链接请求，而服务器认为链接成功则须要文虎相应的资源来管理链接，但这个链接无心义，服务器在维护的时候会浪费服务器资源。形成空间与时间上的浪费，从而形成内存泄漏的问题。四次握手问题同二次握手。(2)三次握手的最后一次传送数据有可能也会形成丢包问题，可是此时客户端认为链接创建成功而服务器认为链接创建没成功，对服务器没有太大的消耗。客户端给服务器端发送数据，服务器端不进行接收。三次握手已经知足需求就不须要更屡次的握手。(3)创建链接是双方的事情，双方都须要创建链接再互相确认，有点像四次握手。可是由于由于TCP能捎带应答，因此服务器向客户端的请求创建链接的SYN以及对客户端的ACK能够一块儿发送，从而致使了三次握手。2.为何是四次挥手？* 释放链接是两方的事情，双方发送断开链接请求后还须要确认，并且服务器对客户端的ACK以及FIN不能合并，因此是四次挥手* 服务器端对客户端的FIN及ACK不能合并是由于客户端断开链接代表客户端没有数据发送给服务器了，不带表服务器没有数据发给客户端，则服务器向客户端发送ACK以后到服务器发送FIN之间有时间间隔，因此两步骤不能合并3.为何有TIME_WAIT状态？如服务器端将最后一个断开链接请求发送以后，客户端收到FIN后给服务器端发送一个确认应答ACK，但在传输过程当中可能会丢包，这个ACK没有被服务器收到。当服务器在必定时间内没有收到ACK时会从新发送请求，因此客户端须要一个TIME_WAIT时间等待，解决丢包重传问题。一个TIME_WAIT的时间是2MSL。哪一方先断开链接就先进入TIME_WAIT等待时间。socket 相关资源：基于Tcp协议的服务器与客户端通信之客户端_tcp客户端与服务器通信...

TCP/IP详解--接收RST回应的几种情况：1、端口未打开服务器程序端口未打开而客户端来连接。这种情况是最为常见和好理解的一种了。去telnet一个未打开的TCP的端口可能会出现这种错误。这个和操作系统的实现有关。在某些情况下，操作系统也会完全不理会这些发到未打开端口请求。2、请求超时曾经遇到过这样一个情况:一个客户端连接服务器，connect返回-1并且error=EINPROGRESS。 直接telnet发现网络连接没有问题。ping没有出现丢包。用抓包工具查看，客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。3、提前关闭关于TCP，我想我们在教科书里都读到过一句话，'TCP是一种可靠的连接'。 而这可靠有这样一种含义，那就是操作系统接收到的来自TCP连接中的每一个字节，我都会让应用程序接收到。扩展资料TCP/IP连接三次握手在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认； SYN：同步序列编号(Synchronize Sequence Numbers)第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。完成三次握手，客户端与服务器开始传送数据。
1、首先，创建tcp服务器，创建的方式如下面图中所示，先创建一个net服务，然后监听connect和data事件，并对收到的数据进行确认，监听端口8431。2、创建tcp客户端，连接上面建立的tcp服务器，并发送 你好，并接收来自服务器的确认信息。3、下面显示的是服务器接收到的数据，并显示出来，然后向客户端发送数据确认。4、显示来自服务器的确认数据，这样一个tcp服务器和客户端就建立起来了。
仅从抓包信息看是服务器的一个流量控制机制启动了。服务器发回rst位，同时win置为0，是告诉客户端不要发包。按tcp流控机制来说，此时客户端应该停止发包，直至服务器发送信息告诉客户端可以继续发送。

首先 客户端向服务器发出请求 然后 服务器确认收到的请教,并发送信号给客户端 最后 客户端收到信号后, 建立连接 并开始传送数据

（1）请求连接时，客户端的SYN_SENT状态下，客户端TCP等待着从服务器TCP发送确认数据段…而其ESTABLISHED状态下，TCP客户可以发送和接收装载着有效载荷数据的TCP数据段。 （2）终止连接时，FIN_WAIT状态下，客户端TCP等待着从服务器发送确认数据段…而其FIN_WAIT_2状态下，客户端等待着服务器发来另一个FIN=1的数据段…而其TIME_WAIT状态下，如果TCP客户最后一次发送的ACK丢失了，它将重新发送。

一直收的那个就不要写输入的代码了，直接无限读取就可以。 一直发的那个就不要写输出的代码了，直接无限输入就可以; 当然如果想两个都想在服务器和客户端各种实现，那么加入多线程吧。一个线程只管输入，一个线程只管输出
写到shell里面，每次启动，启动shell脚本