简介这份资料面向国家开放大学广开/国开电大网络编程技术课程的学习者对应实践技能训练1的参考答案帮助解决制作简易购物车页面时无从下手、代码调试困难等问题。压缩包共5个文件包含html页面结构、css样式表、js交互脚本以及两张jpg图片素材整体约62KB体量轻便便于快速查阅与本地运行验证。资源围绕HTML布局、CSS美化与JavaScript交互三条主线展开涉及商品列表、数量输入、加入购物车按钮、总价计算、输入合法性校验及localStorage数据持久化等典型知识点并延伸至AJAX异步通信思路。目前已有253人学习浏览适合需要对照参考、梳理实现逻辑并完成训练任务的同学可借此理解前端购物车页面的完整构建流程与常见排错方向。1. 从“网络编程技术实践技能训练1”说起一套能跑通的 Socket 编程训练该怎么拆很多同学看到“网络编程技术实践技能训练1”这个标题第一反应是去找一份现成的答案交差。但真正做过这套训练的人都知道它考的不是背诵而是你能不能在一台机器上把 TCP 服务端和客户端从零写出来、跑起来、看到数据来回流动。我带过几届做这个训练的学生翻车最多的地方从来不是代码写不出来而是环境没配对、端口被占用、缓冲区读不完整这些实操细节。这篇笔记就按一线调试的思路把训练1涉及的核心技术点拆开讲先讲清楚 TCP Socket 编程到底在做什么再给出可以直接抄作业的最小可运行代码然后逐条说明参数怎么调、报错怎么看。适合正在做国开电大网络编程技术实践技能训练1、想真正理解而不是复制粘贴的读者也适合需要快速复习 Socket 编程基础的在职开发者。2. TCP Socket 编程的底层逻辑与训练1的考核意图2.1 训练1为什么总是从 TCP 回显开始网络编程技术实践技能训练1的典型任务描述是编写一个基于 TCP 协议的服务端程序和客户端程序客户端发送字符串服务端接收后原样返回客户端再显示出来。这个“回显”模型看起来简单但它把网络编程最核心的几个环节全部串起来了套接字创建、地址绑定、监听、连接建立、数据收发、连接关闭。为什么训练1不直接从 UDP 或者 HTTP 开始因为 TCP 的面向连接特性让每一步都有明确的成功或失败信号。bind失败会报错listen之后才能acceptconnect不通会超时。这些信号对初学者来说是天然的调试锚点。而 UDP 没有连接状态发了就发了收没收到全靠应用层自己判断反而不利于建立“网络编程到底在干什么”的直觉。从考核意图看训练1要验证的是三件事第一你知不知道服务端和客户端的角色差异第二你能不能正确处理字节流——TCP 是字节流协议没有消息边界这一点后面会重点讲第三你能不能独立排查端口占用、防火墙拦截这类环境问题。这三件事在后续训练里会反复出现训练1只是把它们压缩到一个最小场景里。2.2 字节流没有边界训练1最容易忽略的坑TCP 是字节流协议这意味着服务端调用一次recv读到的数据不一定是客户端一次send发出来的完整内容。比如客户端发了 “hello” 五个字节服务端可能第一次recv只读到 “hel”第二次才读到 “lo”。这不是 bug是 TCP 的正常行为。训练1的回显场景里如果客户端发完就关连接服务端循环读到连接关闭为止通常能拿到完整数据。但如果客户端发完不关连接、等服务端回显服务端又只调用一次recv就回写就可能出现“客户端发了 100 字节服务端只回显了 30 字节”的现象。很多同学遇到这个问题会怀疑代码写错了其实是没理解字节流的边界问题。常见做法是在应用层定义一个简单的协议比如“每条消息以换行符结尾”服务端循环读取直到遇到换行符才认为收到一条完整消息。训练1如果只要求回显固定长度的字符串也可以约定“先发 4 字节长度再发内容”但这对初学者来说复杂度偏高。我一般建议训练1阶段先用“客户端发完就 shutdown 写端服务端读到 EOF 为止”的方式简单可靠。2.3 选 Python 还是 C 还是 Java训练1的语言选择国开电大网络编程技术实践技能训练1通常不限定语言但不同语言的调试成本差异很大。C 语言最贴近系统调用能让你看清socket、bind、listen、accept的每一步返回值但内存管理和错误处理代码量大容易在segfault上浪费大量时间。Java 的ServerSocket和Socket封装程度高跨平台好但需要处理异常和流的嵌套对不熟悉 IO 的同学来说反而绕。Python 的socket模块是训练1阶段最平衡的选择它直接暴露了 BSD Socket 的核心接口代码量少报错信息清晰而且不需要编译。下面给出的示例都用 Python但逻辑和参数在 C、Java 里是一一对应的。如果你所在的教学班要求用 C把 Python 的socket()换成socket(AF_INET, SOCK_STREAM, 0)bind换成bind(fd, (struct sockaddr*)addr, sizeof(addr))逻辑完全一样。3. 用 Python 在本地跑通训练1的最小可运行代码3.1 服务端从 socket 到 accept 的完整流程先看服务端代码。这段代码可以直接保存为tcp_server.py在本地运行。import socket # 创建 TCP 套接字 # AF_INET 表示 IPv4SOCK_STREAM 表示 TCP server_sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 设置 SO_REUSEADDR避免重启时端口被 TIME_WAIT 状态占用 server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 绑定地址和端口 # 127.0.0.1 表示只监听本机回环地址换成 0.0.0.0 可接受外部连接 HOST 127.0.0.1 PORT 8888 server_sock.bind((HOST, PORT)) # 开始监听参数 5 表示等待队列最大长度 server_sock.listen(5) print(f服务端已启动监听 {HOST}:{PORT}) while True: # accept 会阻塞直到有客户端连接进来 conn, addr server_sock.accept() print(f客户端 {addr} 已连接) # 循环读取客户端发来的数据 while True: data conn.recv(1024) # 每次最多读 1024 字节 if not data: # 客户端关闭了连接recv 返回空字节 break print(f收到: {data.decode(utf-8)}) # 原样回写 conn.sendall(data) # 关闭与当前客户端的连接 conn.close() print(f客户端 {addr} 已断开)这段代码的逻辑说明socket.socket()创建套接字对象setsockopt设置地址复用bind把套接字绑定到具体 IP 和端口listen把主动套接字转为被动监听套接字accept从已完成连接队列里取出一个连接返回一个新的套接字conn和客户端地址addr。注意conn才是用来收发数据的套接字server_sock只负责监听和接受新连接。参数说明recv(1024)里的 1024 是缓冲区大小表示一次最多读取 1024 字节。这个值可以调大比如 4096 或 8192但不要设得太小否则大消息会被拆成很多次读取。listen(5)里的 5 是 backlog表示内核为该套接字维护的已完成连接队列长度超过这个数量的连接会被拒绝或忽略。本地测试用 5 足够生产环境通常设 128 或更大。3.2 客户端connect、sendall 与 shutdown 的配合客户端代码保存为tcp_client.py在服务端启动后运行。import socket # 创建 TCP 套接字 client_sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 连接服务端 HOST 127.0.0.1 PORT 8888 client_sock.connect((HOST, PORT)) print(f已连接到 {HOST}:{PORT}) # 发送数据 msg hello, network programming client_sock.sendall(msg.encode(utf-8)) # 关闭写端告诉服务端“我不会再发数据了” # 这样服务端的 recv 会返回空字节从而退出循环 client_sock.shutdown(socket.SHUT_WR) # 接收服务端回显的数据 # 因为服务端读到 EOF 后才回写这里需要循环读到 EOF received b while True: chunk client_sock.recv(1024) if not chunk: break received chunk print(f收到回显: {received.decode(utf-8)}) # 关闭套接字 client_sock.close()逻辑说明connect发起三次握手成功后返回。sendall会确保所有数据都写入内核发送缓冲区如果只调用send可能只发送了部分数据需要自己循环。shutdown(socket.SHUT_WR)关闭写端发送 FIN 包服务端recv会返回空字节从而跳出读取循环并回写数据。客户端再循环读取回显数据直到服务端关闭连接。参数说明sendall没有大小限制但底层会分片发送。shutdown的参数SHUT_WR表示只关闭写方向读方向仍然可用这正是回显场景需要的。如果直接close客户端就无法再读取服务端的回显了。3.3 运行验证与预期输出先在一个终端运行服务端python tcp_server.py看到服务端已启动监听 127.0.0.1:8888后在另一个终端运行客户端python tcp_client.py客户端预期输出已连接到 127.0.0.1:8888 收到回显: hello, network programming服务端预期输出服务端已启动监听 127.0.0.1:8888 客户端 (127.0.0.1, 54321) 已连接 收到: hello, network programming 客户端 (127.0.0.1, 54321) 已断开如果客户端卡在recv不返回说明服务端没有正确回写或者没有关闭连接。如果服务端报Address already in use说明端口被占用检查是否有其他程序在监听 8888或者上一次运行的服务端进程没有完全退出。4. 训练1的避坑与排查端口、编码、半关闭的五个血泪经验4.1 现象Address already in use重启服务端就报错原因TCP 连接关闭后主动关闭方会进入TIME_WAIT状态持续 2MSL通常 60 秒左右期间端口不能被重新绑定。如果服务端先关闭连接或者客户端先关闭但服务端没有正确处理端口就会处于占用状态。解决在bind之前设置SO_REUSEADDR。代码里已经加了server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)这一行能让你在TIME_WAIT期间重新绑定同一端口。注意SO_REUSEADDR要在bind之前调用放在socket()之后、bind()之前。4.2 现象客户端收到乱码或者 UnicodeDecodeError原因发送方和接收方的编码不一致。Python 3 的str是 Unicodesend之前必须encode成字节。如果发送方用 UTF-8 编码接收方用 GBK 解码中文就会乱码。训练1如果只发英文通常不会遇到但一旦涉及中文编码问题必然出现。解决统一用 UTF-8。发送端msg.encode(utf-8)接收端data.decode(utf-8)。如果接收到的字节不完整decode会抛UnicodeDecodeError这时候要么等收完整再解码要么用errorsignore先跳过但后者会丢数据不推荐在正式代码里用。4.3 现象服务端只收到一次数据客户端发第二次就没反应原因服务端的recv循环在客户端第一次shutdown后就退出了conn被关闭。如果客户端想复用同一个连接发多条消息服务端不能读到 EOF 就关连接而应该按消息边界来切分。解决训练1如果要求多次交互需要在应用层定义消息边界。最简单的是每条消息以\n结尾服务端用recv循环拼接直到遇到\n才处理一条消息。代码示例如下def recv_line(conn): buffer b while not buffer.endswith(b\n): chunk conn.recv(1) # 逐字节读简单但低效 if not chunk: return None buffer chunk return buffer[:-1] # 去掉换行符逐字节读效率很低实际可以用makefile(rb)或者自己维护缓冲区。训练1阶段如果只做一次回显不需要这一步。4.4 现象本机跑通换一台机器就连不上原因服务端绑定的是127.0.0.1这个地址只接受本机回环连接。另一台机器通过 IP 访问时目标地址不是回环地址连接会被拒绝。另外防火墙可能拦截了 8888 端口的入站连接。解决把HOST改成0.0.0.0表示监听所有网络接口。然后确认两台机器在同一网段用ping测试连通性。如果还连不上检查防火墙规则临时关闭防火墙测试或者添加入站规则放行 8888 端口。注意0.0.0.0在有些系统上表示所有 IPv4 地址绑定后本机回环和外部 IP 都能访问。4.5 现象recv 返回空字节但客户端明明发了数据原因recv返回空字节只有一个含义对端关闭了连接收到 FIN 包。如果客户端调用了close或shutdown(SHUT_WR)服务端就会读到空字节。如果客户端还没发数据就关闭了服务端自然读不到内容。解决检查客户端的发送逻辑确认sendall在shutdown之前调用。另外如果客户端进程崩溃或者被强制杀死操作系统会发送 RST 包服务端recv会抛ConnectionResetError而不是返回空字节。这时候需要捕获异常并清理连接。5. 从训练1到真实网络程序用 tcpdump 和 ss 验证你的 Socket 行为训练1的代码跑通只是起点。真实网络程序里你需要确认数据到底有没有发出去、连接处于什么状态、内核缓冲区里还有多少数据。这里给两个我常用的验证手段不需要改代码就能看清底层行为。第一个是ss命令用来查看套接字状态。在服务端运行后执行ss -tlnp | grep 8888输出会显示LISTEN状态的套接字和对应的进程。客户端连接后再执行ss -tnp | grep 8888你会看到ESTAB状态的连接以及发送队列和接收队列的字节数。如果Send-Q一直不为零说明数据积压在内核缓冲区没发出去通常是网络阻塞或者对端接收窗口满了。第二个是tcpdump用来抓包看三次握手和四次挥手。在 Linux 上执行sudo tcpdump -i lo port 8888 -nn然后运行客户端你会看到SYN、SYN-ACK、ACK三次握手接着是PSH包携带数据最后是FIN、ACK四次挥手。这个视角能让你直观看到connect、sendall、shutdown分别对应哪个 TCP 包。Windows 上可以用 Wireshark 代替过滤条件写tcp.port 8888。我自己的习惯是每次写新的 Socket 程序先用ss确认监听状态再用tcpdump抓一次完整交互。这两个工具能帮你区分“代码问题”和“网络问题”。比如客户端connect超时抓包看到SYN发出去了但没有SYN-ACK那就是服务端没监听或者防火墙拦截如果看到RST返回那就是端口没开或者服务端拒绝连接。这种排查方式比在代码里加print高效得多。训练1的代码虽然简单但它是后续所有网络编程训练的骨架。把这一套跑熟知道每个系统调用的含义、每个参数的作用、每个报错的排查方向后面做多线程服务端、IO 多路复用、自定义协议都只是在这个骨架上加东西。希望帮到你。本文还有配套的精品资源点击获取