(一) TCP介绍TCP协议。 传输控制协议(TCP ) )是由IETF的RFC 793定义的面向连接且可靠的基于字节流的传输层通信协议
TCP通信需要创建连接、传输数据和终止连接三个步骤。
在TCP通信模型中，在通信开始之前，一定要建立相关的链路，然后才能发送数据。 在生活中，和“打电话”很像
) TCP特征1 .面向连接通信的双方在进行数据传输之前必须建立连接，双方都必须为该连接分配管理连接的状态和连接上的传输所需的系统内核资源。
双方之间的数据传输可在该1个连接上进行。
数据交换完成后，双方必须断开此连接以释放系统资源。
TCP不适用于广播APP应用程序，因为此连接是一对一的。 对于基于广播的APP应用程序，请使用UDP协议。
2 .可靠的转发1 )如果使用发送应答机制从TCP发送的各段没有得到接收侧的响应，则TCP并不认为该TCP段的转发成功
2 )超时再发送方在发送1个段后，启动定时器，如果在定时时间内没有应答的话，再发送该段。
TCP为了确保不发生分组丢失，对每个分组赋予序号，同时序号确保转发给接收实体的分组的依次接收。 接着，接收实体针对成功接收的分组发送适当确认(ACK )； 如果发送实体在合理的往返延迟(RTT )内没有接收到确认，则假设丢失了对应的分组而被重发。
3 )错误检查TCP使用校验和函数检查数据是否有错误； 发送和接收时计算校验和。
4 )流量控制和拥塞管理流量控制用于避免主机发送过快，导致接收方无法完全接收。
(三) TCP和UDP的不同点是面向连接的(确认三方握手被制作，连接被制作后再发送。 )有序的数据传输(重传丢失的分组)丢弃重复的分组无错误的数据传输拥塞/业务控制1.udp通信模型在udp通信模型中，不需要在通信开始之前建立相关链路，只需要传送数据。 在生活中，与“写信”)相似
2.tcp通信模型在TCP通信模型中，在通信开始前，一定能建立相关的链路，然后再发送数据。 在生活中，和“打电话”很像
(4) tcp客户机tcp客户机不是如上所述的素材。 有个客人去餐厅吃饭，这个客人想点菜，我问服务员我们酒店有没有客户，这位服务员非常有礼貌地说。 “先生，我们酒店不用客户，直接送到您的餐桌上
如果不学习网络知识的话，有可能发生这样的笑话吗，哈哈
服务器端是指提供服务的一侧，客户端是指提供服务的一侧
1.tcp客户端构建过程tcp的客户端比服务器端简单得多。 如果服务器端需要自己购买手机、查手机卡、安装铃声、等待别人打电话的流程，那么客户端只需要找一个电话亭，拿起电话打电话就可以了，过程相当少
示例代码：
创建fromsocketimport * # socket TCP _ client _ socket=socket (af _ inet )并创建sock_stream(# ) 目标信息server_ip=input (请输入“服务器ipip:”) server _ port=int (请输入“服务器端口：”) #链接服务器数据send_data=input ('请输入要发送的数据： ' (TCP_client_socket.send ) send_data.encode(gbk ) )最能提示用户
买手机，插入手机卡，设计成手机可以正常接收信息。 也就是说，可以按铃。 静静地等着别人给2.tcp服务器打电话。 与上述电话流程一样，在程序中，要完成tcp服务器的功能，需要的流程如下。
创建套接字。 套接字绑定ip和portlisten使套接字成为一个简单的tcp服务器，客户端链接recv/send可以被动链接accept以等待数据的发送和接收。
fromsocketimport * # socket TCP _ server _ socket=socket (af _ inet，SOCK_STREAM )本地信息address=('，788 ) # TCP 本地信息这样就可以接收到指向TCP_server_socket.listen的其他链接
门为这个客户端服务# client_socket用来为这个客户端服务# tcp_server_socket就可以省下来专门等待其他新客户端的链接client_socket, clientAddr = tcp_server_socket.accept()# 接收对方发送过来的数据recv_data = client_socket.recv(1024) # 接收1024个字节print('接收到的数据为:', recv_data.decode('gbk'))# 发送一些数据到客户端client_socket.send("thank you !".encode('gbk'))# 关闭为这个客户端服务的套接字，只要关闭了，就意味着为不能再为这个客户端服务了，如果还需要服务，只能再次重新连接client_socket.close() 六：注意事项 tcp服务器一般情况下都需要绑定，否则客户端找不到这个服务器tcp客户端一般不绑定，因为是主动链接服务器，所以只要确定好服务器的ip、port等信息就好，本地客户端可以随机tcp服务器中通过listen可以将socket创建出来的主动套接字变为被动的，这是做tcp服务器时必须要做的当客户端需要链接服务器时，就需要使用connect进行链接，udp是不需要链接的而是直接发送，但是tcp必须先链接，只有链接成功才能通信当一个tcp客户端连接服务器时，服务器端会有1个新的套接字，这个套接字用来标记这个客户端，单独为这个客户端服务listen后的套接字是被动套接字，用来接收新的客户端的链接请求的，而accept返回的新套接字是标记这个新客户端的关闭listen后的套接字意味着被动套接字关闭了，会导致新的客户端不能够链接服务器，但是之前已经链接成功的客户端正常通信。关闭accept返回的套接字意味着这个客户端已经服务完毕当客户端的套接字调用close后，服务器端会recv解堵塞，并且返回的长度为0，因此服务器可以通过返回数据的长度来区别客户端是否已经下线 七：TCP的三次握手和四次挥手 1.三次握手
（1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。
（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。
（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据。
2.四次挥手由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
CP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。
（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。
八：TCP长连接和短连接TCP在真正的读写操作之前，server与client之间必须建立一个连接，
当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，
连接的建立通过三次握手，释放则需要四次握手，
所以说每个连接的建立都是需要资源消耗和时间消耗的。
1. TCP短连接模拟一种TCP短连接的情况:
client 向 server 发起连接请求server 接到请求，双方建立连接client 向 server 发送消息server 回应 client一次读写完成，此时双方任何一个都可以发起 close 操作在步骤5中，一般都是 client 先发起 close 操作。当然也不排除有特殊的情况。
从上面的描述看，短连接一般只会在 client/server 间传递一次读写操作！
2. TCP长连接再模拟一种长连接的情况:
client 向 server 发起连接server 接到请求，双方建立连接client 向 server 发送消息server 回应 client一次读写完成，连接不关闭后续读写操作...长时间操作之后client发起关闭请求3. TCP长/短连接操作过程 3.1 短连接的操作步骤是：
建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接
3.2 长连接的操作步骤是：
建立连接——数据传输...（保持连接）...数据传输——关闭连接
4. TCP长/短连接的优点和缺点长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。
对于频繁请求资源的客户来说，较适用长连接。
client与server之间的连接如果一直不关闭的话，会存在一个问题，
随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，
如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；
如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，
这样可以完全避免某个蛋疼的客户端连累后端服务。
短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。 但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。 5. TCP长/短连接的应用场景长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。
每个TCP连接都需要三次握手，这需要时间，如果每个操作都是先连接，
再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，
再次处理时直接发送数据包就OK了，不用建立TCP连接。
例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，
而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，
而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，
如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，
那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。
九：文件下载器 from socket import *import sysdef get_file_content(file_name): """获取文件的内容""" try: with open(file_name, "rb") as f: content = f.read() return content except: print("没有下载的文件:%s" % file_name)def main(): if len(sys.argv) != 2: print("请按照如下方式运行：python3 xxx.py 7890") return else: # 运行方式为python3 xxx.py 7890 port = int(sys.argv[1]) # 创建socket tcp_server_socket = socket(AF_INET, SOCK_STREAM) # 本地信息 address = ('', port) # 绑定本地信息 tcp_server_socket.bind(address) # 将主动套接字变为被动套接字 tcp_server_socket.listen(128) while True: # 等待客户端的链接，即为这个客户端发送文件 client_socket, clientAddr = tcp_server_socket.accept() # 接收对方发送过来的数据 recv_data = client_socket.recv(1024) # 接收1024个字节 file_name = recv_data.decode("utf-8") print("对方请求下载的文件名为:%s" % file_name) file_content = get_file_content(file_name) # 发送文件的数据给客户端 # 因为获取打开文件时是以rb方式打开，所以file_content中的数据已经是二进制的格式，因此不需要encode编码 if file_content: client_socket.send(file_content) # 关闭这个套接字 client_socket.close() # 关闭监听套接字 tcp_server_socket.close()if __name__ == "__main__": main() server from socket import *def main(): # 创建socket tcp_client_socket = socket(AF_INET, SOCK_STREAM) # 目的信息 server_ip = input("请输入服务器ip:") server_port = int(input("请输入服务器port:")) # 链接服务器 tcp_client_socket.connect((server_ip, server_port)) # 输入需要下载的文件名 file_name = input("请输入要下载的文件名：") # 发送文件下载请求 tcp_client_socket.send(file_name.encode("utf-8")) # 接收对方发送过来的数据，最大接收1024个字节（1K） recv_data = tcp_client_socket.recv(1024) # print('接收到的数据为:', recv_data.decode('utf-8')) # 如果接收到数据再创建文件，否则不创建 if recv_data: with open("[接收]"+file_name, "wb") as f: f.write(recv_data) # 关闭套接字 tcp_client_socket.close()if __name__ == "__main__": main() client
转载于:https://www.cnblogs.com/huiyichanmian/p/11342793.html