上一章节，演示了Module Proxy将HTTP转发为Socket的一个示例，本章将揭示Module Proxy的工作细节。
数据交换
传统上浏览器客户端提交数据时，将数据打包为 “名称=值” 这种键值对形式，比如在登录认证时提交账号和密码到服务端去验证：
http://mydomain.com:80/login.php?name=admin&passwd=mypasswd
在Module Proxy Socket代理中并不使用这种数据包装形式，而是采用 Body Json 的数据形式：
1）数据封装为Json格式，POST方式发送。
2）数据没有名称，Json作为整体放在HTTP Body中发送。
示例中，Ajax客户端提交的数据：
{"head":{"method":"aaa.BBB::hello"},"data":{"hello":"world!!!","list":[1,2,3,4]}}
经过Module Proxy代理转换后，发送给Java和Go的数据改变为：
81
{"head":{"method":"aaa.BBB::hello"},"data":{"hello":"world!!!","list":[1,2,3,4]}}
注意经过Module Proxy 转发后多了一行数据，81表示json数据的长度，前面有8个空格，后面有“\r\n”2个字节，长度行一共12个字节。Socket服务端程序读取数据时先读取12字节，从中获得Json的长度信息，再根据长度定义去读取Json。这种先发送一个固定字节的长度单元，再发送数据是Socket传输常用的方式。
同样，Socket服务端程序返回的数据，也要添加一个相同的12字节格式的长度单元，以方便Module Proxy读取。
接口
传统前后台编程时，在调用不同接口时通过 HTTP Url 来进行匹配，例如下面两个Url在后台会映射到不同的函数或方法：
http://mydoamin.com/module/aaa
http://mydoamin.com/module/bbb
Module Proxy 进行Socket代理时是丢弃HTTP协议的，无法使用Url来匹配接口，因此接口的配置直接放入Json。在示例中Json分为head和data两部分，head中可以定义接口、token、SessionId等属性，data内放置“业务”数据。
针对不同的场景需求，项目团队可在head中定义简单的名称规范，比如用method表示调用接口名称、用token或sessionId保持登录用户状态、用zip来表示数据是否压缩，用secret表示是否加密等，如：
{
"head":{
"method":"addUser",
"token":"677c4681-690a-468f-8020-b89822112619",
"secret":"DES",
"secret_key":"abcDEF123"
},
"data":{
"姓名":"张三",
"登录名":"zhangsan",
"登录密码":"fed767276c7d9ba436dd431190c196ec",
"性别":"女",
"职务":"科长",
"手机":"13900001234"
}
}
Socket后端程序
在上一章节的示例中，我们分别用Java和Golang语言搭建了Socket后端服务，实质上Module Proxy对Socket后端用哪种语言没有限制，并鼓励研发人员在项目中“因地制宜”地选用合适的编程语言，这里有一些技术说明：
1）Module Proxy和Sokcet后端程序采用TCP Socket协议，通讯过程中Module Proxy是TCP客户端，Sokcet后端程序是TCP服务端。
2）Socket协议采用“短连接”方式，Module Proxy发送数据后立即关闭本端发送连接，Socket后端程序在应答数据后也应即刻关闭本端连接。
3）对于一个请求-回复周期（短连接周期），Socket服务程序可采用1:1线程或进程模型，或使用更加流行的epoll或事件异步模型。示例中Java服务程序采用了1:1线程模型，而Golang采用了“时尚”的协程。
HTTP的改变
HTTP交互发展了这么多年，形成了一些固定用法和模式，对于Module Proxy需要对这些传统用法进行改变：
1）HTTP提交中的Url和参数，如：
http://mydomain.com:80/user/login.php?name=admin&passwd=mypasswd
通常HTTP后端程序通过Url映射服务接口，通过“名称=值”来获取数据。在使用Module Proxy Socket代理时需要改变原有的这些做法，Url中描述的接口需放在Json的head中进行描述，数据需包装在Json的data中。
2）HTTP提交数据时有GET、POST、HEAD、DELETE等方式，对于Module Proxy Socket代理这些方式已无意义，因为提交数据始终采用Body Json，且经过Socket代理后HTTP相关信息已被丢弃，因此客户端提交时要求始终使用POST方式。
3）大部分情景下，都可以把原来的HTTP交互方式，改变成符合Module Proxy Socket代理要求的交互方式，但有少量情景需要保持HTTP的交互。比如文件上传，或已有的项目不愿做架构改动的，仍然需要使用标准的HTTP后端程序。有关这部分的信息，请看本系列文档的下一章节：兼容传统。
