网络编程——4. 基于TCP的服务器端/客户端（1）

4.1 理解TCP和UDP

根据数据传输方式的不同，基于网络协议的套接字分为TCP和UDP套接字
TCP（Transmission Control Protocol）传输控制协议

TCP/IP协议栈

开放式系统：以多个标准为依据设计的系统，TCP/IP协议栈也属于其中之一，开放式系统使协议设计更容易。
路由器用来完成IP层交互任务。比如某公司原来用A公司的路由器，想换成B公司的，也可以，而不一定要换成同一公司的同一型号的路由器，因为所有生产商都会按照IP层标准制造
再比如所有的网卡制造商都会遵守链路层的协议标准
这些都是开放式系统的优点。

链路层

链路层是物理链接领域标准化的结果，专门定义LAN、WAN、MAN等网络标准。
若两台主机通过网络进行数据交换，则需要如图所示的物理连接，链路层就负责这些标准

IP层

准备好物理链接后就要开始传输数据了。
为了在复杂的网络中传输数据，首先要考虑向目标传输数据需要经过哪条路径？
解决此问题的办法就是IP层，该层使用的协议就是IP。但IP协议无法对应数据错误。

TCP/UDP层

IP层解决数据传输中的路径选择问题，只需要照此路径传输数据即可。

TCP/UDP层以IP层提供的路径信息完成数据传输，又称为传输层

IP层只关注1个数据包（数据传输的基本单位）的传输过程。
因此，即使传输多个数据包，每个数据包也是由IP层实际传输的，也就是说传输顺序及传输本身是不可靠的。
若只利用IP层传输数据，则有可能导致后传输的数据包B比先传输的数据包A提早到达，甚至数据包B可能已损毁

由于这样的原因，就需要添加TCP协议
在数据交换的过程中可以确认对方已经收到数据，并重传丢失的数据，保证了通信的可靠性。

应用层

编写软件的过程中，只需要根据程序特点决定服务器和客户端之间的数据传输规则，这就是应用层协议。
网络编程的大部分内容就是设计并实现应用层协议。

---

---

4.2 实现基于TCP的服务器端/客户端

TCP服务器端的默认函数调用顺序

进入等待连接请求状态

服务器端套接字是接收连接请求的一个门卫

受理客户端连接请求

TCP客户端的默认函数调用顺序

创建套接字和请求连接就是客户端的全部内容

可以看到，在客户端中，没有出现bind函数去实现套接字地址分配，而是创建套接字后立即调用connect函数。
难道客户端无需分配IP和端口吗？不，网络数据交换必须分配IP和端口
何时？调用connect函数时
何地？操作系统，准确地说是在内核中
如何？IP用计算机（主机）的IP，端口随机
客户端的IP地址和端口在调用connect函数时自动分配，无需调用标记的bind函数进行分配

基于TCP的服务器端/客户端函数调用关系

二者并非相互独立的，交互过程如下

服务器端创建套接字后连续调用bind、listen函数进入等待状态。
客户端只有在服务器端调用listen函数后才能调用connect函数。
客户端调用connect函数前，服务器端有可能率先调用accept函数。当然，此时服务器端在调用accept函数时进入阻塞状态，直到客户端调用connect函数为止。

---

---

4.3 实现迭代服务器端/客户端

编写回声（echo）服务器端/客户端。服务器端将客户端传输的字符串原封不动地传回客户端。

服务器端设置好等待队列的大小后，应向所有客户端提供服务。如果想继续受理后续的客户端连接请求，最简单的办法是反复调用accept函数。如图

可以看到，调用close函数并非针对服务器端套接字，而是针对accept函数调用时创建的套接字，意味着结束了针对某一客户端的服务，此时如果还想服务于其他客户端，就需要重新调用accept函数，这样就可以解释为什么箭头是从close（client）之后指向accept之前了。

这个时候，你可能会说。好歹是个服务器，同一时刻只能服务于同一个客户端吗？
不，是因为你还没有学进程和线程。

回声客户端存在的问题

由于在客户端中，如果我们多次调用write函数，传递的字符串有可能一次性传递到服务器端。此时客户端有可能从服务器接收到多个字符串。这不是我们希望看到的结果。还需要考虑服务器端的如下情况：
字符串太长，需要分2个数据包发送！！

1）服务器端希望通过调用1次write函数传输数据，但如果数据太大，操作系统有可能把数据分成多个数据包发送到客户端
2）在此过程中，客户端有可能在尚未收到全部数据包时就调用了read函数