《Windows平台下TCPIP协议的设计与实现》由会员分享，可在线阅读，更多相关《Windows平台下TCPIP协议的设计与实现（20页珍藏版）》请在金锄头文库上搜索。
1、 目 录1. 引言12. TCP/IP协议概述13.TCP/IP协议的系统设计24.TCP/IP协议的系统实现35. 结论116. 详细设计代码12Windows平台下TCP/IP协议的设计与实现 1. 引言本文背景基于一个TCP/IP协议改进项目，项目要求通过改进TCP/IP协议拥塞控制算法 来提高无线网络环境下的数据吞吐量。目前的TCP协议在无线网络环境下无法区分出拥塞 丢包与误码丢包，根据这两种不同的丢包原因需要对TCP的窗口进行不同的调整，因此需 要对现有的TCP/IP协议进行改进。针对这个需求提供的一个解决方案就是自己开发出一套 TCP/IP协议以替代系统TCP/IP协议，但是并不需
2、要实现整个TCP/IP协议族，重点实现TCP 与IP协议即可。2. TCP/IP协议概述TCP/IP协议是Internet的技术基础。Internet是一个广域网，是目前联通世界上绝大多 数国家和地区的全球性信息系统。在Internet上，可以实现低成本、高速率、交互式的信息 查询、信息发布、通讯联络以及协同作业等等现代化的工作、学习和生活。TCP/IP协议族通常分为四个层次，应用层、传输层、网络层和链路层。如图1所示:应用层(FTP, SMTP等）传输层(TCP，UDP等）网络层(IP, ICMP等）链路层(网卡驱动等）图1 TCP/IP协议族四层结构应用层向用户提供一组常用的应用程序，比如
3、电子邮件(SMTP)、文件传输访问(FTP)、 远程登录(Telnet)等。传输层提供进程间端到端的通信。在TCP/IP协议族中，主要有两种不同的传输协议： 传输控制协议(TCP)和用户数据报协议(UDP)。TCP提供面向連接的、可靠的(没有数据重复 或丢失)，全双的数据流传输服务。而UDP则提供的是不可靠的面向无连接的数据传输服 务，其可靠性应由上层应用程序来支持。网络层，主要负责数据包的分组及路由选择。在TCP/IP协议族中，网络层协议包括网际协议IP、互连网控制报文协议ICMP、地址转换协议ARP和反向地址转换协议RARR。链路层处于四层结构的最低层，负责接收IP数据报并通过网络发送之，
4、或从网络上接 收物理帧，抽出IP数据报，交给IP层。通常包括网络设备驱动程序及网络接口卡等。3.TCP/IP协议的系统设计以Windows网络体系结构为基础，参照Windows DDK中关于网络协议驱动与传输驱 动接口 (TDI)的相关资料，以及考虑到与原有系统TCP/IP兼容，提出的设计方案如图2所示。图2 TCP/IP协议设计框图应用程序也就是根据协议开发的特定应用。这里是针对开发的TCP/IP协议编写的一个 FTP小应用程序，用来测试开发的协议。应用程序通过Wm32 API3接口将其操作转化成相 应的请求提交给TDI客户。传输驱动程序接口（TDI)客户是核心态的驱动程序。它的主要功能是完
5、成上层应用 程序的请求，或者根据该请求产生相应的TDI操作，并将该操作传递给下层的TDI传输器。 TDI客户通过Win32 API接口与上层应用程序交互；通过TDI接口与下层TDI传输器进行交互。TDI传输提供者（TDI Transport Provider)又称为TDI传输器，NDIS协议驱动程序，以及协议驱动程序，是工作在核心态的协议驱动程序。其中TCP协议，IP协议，ARP协议 等都是在这个模块中实现。它通过TDI接口与上层的TDI客户进行交互；通过NDIS接口 与下层微端口驱动进行交互。NDIS下层微端口驱动程序是工作在核心态的驱动程序，它负责将TDI传输器接入至特 定的网络适配器。它
6、通过NDIS接口与上下层进行交互。4.TCP/IP协议的系统实现由图2中可以看出，整个系统可分为四部分，应用程序、TDI客户、TDI传输器和下层 微端口驱动。事实上对于下层微端口驱动并不需要考虑，因为可以直接调用NDIS库函数将 数据转发到这层，处于这层上的驱动会自动将数据送出网络适配器。因此真正需要开发的也 就是上面三个部分。应用程序是用来实现简単文件传输的，因此考虑开发两个小应用程序， 一个为服务器端，一个为客户端，服务器端用来监听和处理来自客户端的连接请求。客户端 主要是向服务器端请求连接和发送数据。TDI客户负责将来自应用程序的请求进行相应的处 理之后转发给下层的TDI传输驱动。TDI
7、传输驱动主要是实现TCP, IP等功能，并与下层的 NDIS接口进行交互。4.1 应用程序的实现 客户端可以通过本地的某个端口向对方发送数据。并显示一些错误状态。服务器端，可以指定在本地的某个端口监听连接请求，接收数据，并显示一些状态。实现：通过DeviceIOControl 及相应ControlCode 来将命令传输到下层的TDI 客户。主要接口函数：CreateFile 和DeviceIoControlCreateFile 函数原型：HANDLE CreateFile(LPCTSTR lpFileName,DWORD dwDesiredAccess,DWORD dwShareMode,LP
8、SECURITY_ATTRIBUTES lpSecurityAttributes,DWORD dwCreationDisposition,DWORD dwFlagsAndAttributes,HANDLE hTemplateFile);lpFileName 在这里就是指向要操作的TDI 客户（驱动）的符号链接，符号链接是下层驱动程序对Win32 子系统可见的引用符号，也就是代表了一个下层的驱动。这个函数的功能是打开下层的TDI 客户，并返回该设备句柄，以后对设备的所有操作都是通过该句柄来引用。DeviceIoControl 函数原型：BOOL DeviceIoControl(HANDLE hD
9、evice,DWORD dwIoControlCode,LPVOID lpInBuffer,DWORD nInBufferSize,LPVOID lpOutBuffer,DWORD nOutBufferSize,LPDWORD lpBytesReturned,LPOVERLAPPED lpOverlapped);hDevice 和dwIoControlCode 是这里最重要的两个参数。前者是前面CreateFile 返回的句柄，代表设备对象，在这里即是下层的TDI 客户，表明是对它进行操作；后者是I/O 控制码，表明要在该设备上进行的操作类型，如发送数据，这个控制码可以是自定义的。在应用程序调
10、用了DeviceIoControl 之后就将操作请求提交给了处于系统内核中的TDI客户。4.2 TDI 客户的实现TDI 客户将上层应用程序发过来的I/O 请求包 (IRP)进行处理，能在本层处理的则处理后直接返回，需要底层继续完成的则先将当前的IRP 状态设置为挂起，然后重新设置一个IRP 移交给下层驱动继续处理。实现： 主要是TirdcTcpIoControlDispatch 派遣例程的实现。这个派遣例程与DeviceIoControl 函数相对应。其主要功能是根据应用程序的不同请求（携带在IRP 中的IoControlCode）进行不同的处理。只是这里需要额外考虑的是，需要在TDI 客户
11、的该例程中事先判断下是对服务器端的TDI 客户操作还是针对客户端的TDI 客户进行操作。主要接口函数：XXX_IOControlDispatch，TdiBuildXXX 和IoCallDriver。XXX_IOControlDispatch 函数原型：NTSTATUSXXX_DeviceIoControl(IN PDEVICE_OBJECT pDeviceObject,IN PIRP pIrp);驱动程序中注册的派遣例程都是pDeviceObject 和pIrp 这两个参数，前面代表了要操作的设备对象，后者代表I/O 请求类型。pDeviceObject 在这里具体的是只指服务器端的TDI客户
12、或客户端的TDI 客户。现在以服务器的TDI 客户为例，假设要对其进行一个监听操作，则此时IRP 中所携带的IoControlCode 则是一个代表监听操作的控制码。这个函数就是根据不同的控制码来决定要进行的操作直接完成IRP 或者是转发请求到下层。对于我们的协议来说，很多情况下TDI 客户是不能独立完成一个IRP 请求的，需要转发到下层也就是它的TDI 传输器来继续完成IRP 的。这个时候就会用到后面的两个重要函数TdiBuildXXX,和IoCallDriver 了。TdiBuildXXX 函数原型：根据 IO 控制码的不同，该函数的声明也稍有区别。仍旧接着前面的事例，TDI 客户不能够独
13、自完成应用程序的监听请求，因此需要借助TdiBuildXXX 函数来生成相应的IRP，交给下层的TDI 传输器进行处理。这里的XXX 既代表不同的操作，对于监听来说，既是TdiBuildListen。其函数原型如下：VOIDTdiBuildListen(PIRP Irp,PDEVICE_OBJECT DevObj,PFILE_OBJECT FileObj,PVOID CompRoutine,PVOID Contxt,ULONG Flags,PTDI_CONNECTION_INFORMATION RequestConnectionInfo,PTDI_CONNECTION_INFORMATION
14、ReturnConnectionInfo);这个函数中最重要的三个参数是Irp、DevObj 和FileObj，第一个是预先分配好的一个IRP 结构体指针；第二个是这个IRP 将要转发到的设备对象，也就是TDI 传输器；第三个是TDI 传输器的文件对象指针，可以是代表传输地址的文件对象，可以是代表连接端点的文件对象，可以是代表控制信道的文件对象，不同的文件对象上可以进行的操作也不一样，比如TDI_LISTEN 操作只可以在代表连接端点的文件对象上进行。该函数主要是对新建的IRP 进行设置，关键是给这个IRP 设置了操作码为TDI_LISTEN. 在创建了这个IRP 以后，TDI 客户将这个IR
15、P 请求转发到它的TDI 传输器，这个过程是通过调用IoCallDriver 函数来实现的。IoCallDriver 函数原型：NTSTATUSIoCallDriver(IN PDEVICE_OBJECT DeviceObject,IN OUT PIRP Irp);该函数将IRP 请求转发给指定的设备对象。在我们的程序中，既是将TDI 客户中生成的IRP 发给下层的TDI 传输器，即我们的协议驱动进行处理。DeviceObject 为代表下层TDI传输器的设备对象，IRP 为要进行的操作，如前面事例中生成的TDI_LISTEN 请求。在 TDI 客户调用IoCallDriver 之后，IRP 请求就转到了TDI 传输器，即我们的TCP/IP协议中处理了。4.3 TDI 传输器的实现TDI 传输器也就是我们的协议驱动，也就是TCP/IP 协议。简单的说，这层的主要操作仍然是根据上层TDI 客户提交过来的请求进行不同的处理。只不过这里又有特殊的含义，就是要完成TCP/IP 的相应功能，因此这一层是我们实现中最重要的部分。在这层中，TDI 传输器接收
