android、ios客户端和服务器通信一般使用什么方式，各有什么优缺点？

1、从网络协议上来看，就http方式和socket方式。

2、http方式开发起来效率想对要高一点，但是对于推送这种来说，想对要难做点，因为http是短连接。socket这种方式开发要长，调试略微麻烦，但是做推送想对简单，可以建立一个长连接。

3、Web Service服务其实也是基于HTTP协议（它基于SOAP协议，而SOAP又是基于HTTP协议）。

最大缺点我觉得是Web Service实在是太厚重了，特别对于移动端来说，WSDL是基于XML，XML已经够厚重了，WSDL还有一些头信息，更加厚重。

而且JSON + HTTP的方式，相对来说就非常轻量级了，JSON格式数据本生就是Javascript中的数据或者对象，所以在网络传输中具有非常明显优势，可以说本来就是网络传输用的，毫无违和感嘛：）

还有一个不能算缺点的缺点：目前移动端HTTP网络库多的要死，Web Service我所知道就是ksoap2，而且非常的难用。。。

OSI 的七层协议体系结构的概念清晰,理论完整,当时它既复杂又不实用; TCP/IP 体系结构则不同,但是它现在却得到了非常广泛的应用,不过从实质上讲, TCP/IP 只是最上面的三层,因为最下面的网络接口层并没有什么具体内容;因此在学习计算机网络的时候往往采取折中的方法,即综合 OSI 和 TCP/IP 的优点,采用一种只有五层协议的体系结构;

iOS 开发中的网络通信主要是在传输层和应用层进行一些网络 IP 地址,端口以及协议的一些处理;首先是网络层的两种传输协议 UDP 和 TCP 的含义以及区别:

用户数据包协议;UDP 在传输数据之前不需要先建立连接远地主机的运输层在收到 UDP 报文后,不需要给出任何确认;

主要特点:

传输控制协议; TCP 提供面向连接的服务;在传输数据之前必须先建立连接,数据传输完成后要释放连接;建立连接需要通过三次握手,而释放连接需要四次握手;

主要特点:

第一次握手：客户端发送syn包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认;

第二次握手：服务器收到syn包，必须确认客户的SYN(ack=x+1)，同时自己也发送一个SYN包(seq=y)，即SYN+ACK包，此时服务器进入SYN_RECV状态;

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

这个问题的本质就是信道不可靠，但是通信双方需要中间传输的数据是可靠的，而要解决这个问题，无论你是在信息中包含什么信息，三次通信是理论上的最小值，所以三次握手不是TCP本身的要求，而是为了满足在不可靠信道上可靠的传输信息这一需求所致的；这里的本质需求就是，信道不可靠，数据传输要可靠，三次握手之后你先继续握手还是发数据也好，跟进行可靠信息传输的需求就没关系了，因此如果信道可靠，无论什么时候发出消息，对方一定能收到，或者你不关心是否要保证对方收到你的消息，那就能像UDP那样直接发送消息就可以；

1当主机A确认发送完数据且知道B已经接受完了，想要关闭发送数据接口（当然确认信号还是可以发），就会发FIN给主机B；

2主机B收到A发送的FIN，表示收到了，就会发送ACK回复；

3但是这时B可能还在发送数据，没有想要关闭数据口的意思，所以FIN和ACK不是同时发送的，而是等到B数据发送完，才会发送FIN给主机A；

4A收到B发来的FIN，知道B的数据也发送完了，回复ACK，A等待2MSL以后，没有收到B传来的任何消息，知道B已经收到自己的ACK了，A就关闭链接，B也关闭链接；

在客户端发送最后的ACK回复，但是该ACK可能丢失。服务端如果没有收到ACK，将不断重复发送FIN片段。所以客户端不能立即关闭，它必须确认服务端接收到了该ACK，客户端会在发送出ACK之后进入到TIME_WAIT状态，客户端会设置一个计时器，等待2MSL的时间，如果在该时间内再次收到FIN，那么客户端会重发ACK并再次等待2MSL；所谓2MSL是两倍的MSL（Maximum Segment Lifetime）。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果知道2MSL，客户端都没有再次收到FIN，那么客户端推断ACK已经成功接收，则结束TCP连接；

HTTP是一种无状态的连接，客户端每次读取web网页时，服务器都会认为这是一次新的会话。但有时候我们需要持久保存一些用户信息，比如登录时的用户名和密码等；而这些信息都是需要Cookie和Session来保存；

这两个的本质区别就是Cookie是保存在客户端的，而Session是保存在服务器上的；

当服务器接收到 cookie 后，会根据 cookie 中的 SessionID 来找到这个客户的 session。如果没有，则会生成一个新的 SessionID 发送给客户端。

HTTP 连接使用的是"请求--响应"的方式,不仅在请求时需要先建立连接,而且需要客户端向服务器发出请求后,服务器端才能回复数据;一次请求后立即断开;HTTP 使用的的面向连接的 TCP 作为传输层协议,保证了数据的可靠性;但是 HTTP属于无状态,无连接;虽然使用了 TCP 连接,但通信的双方不需要先建立连接;

socket 连接通常情况下就是 TCP 连接,因此 socket 连接一旦建立,通信双方即可开始互相发送数据内容,直到双方的连接断开;但在实际应用中,客户端和服务器之间的通行防火墙会关闭长时间处于非活跃状态的连接而导致 socket 连接中断,因此需要通过轮询告诉网络该连接处于活跃状态;

连接过程分为三个步骤:服务器监听,客户端请求,连接确认;

服务器监听 :服务器端套接字并不定位具体的客户端套接字,而是处于等待连接状态,实时监测网络状态,等待客户端的连接请求;

客户端的连接请求 :指客户端的套接字提出连接请求,要连接的目标是服务器端的套接字,为此客户端的套接字必须首先描述它要连接的服务器的套接字,指出服务器端的套接字的地址和端口号,然后就向服务器端套接字提出连接请求;

连接确认 :当服务器端套接字监听到或者说收到客户端套接字的连接请求时,就响应客户端套接字的请求,建立一个新的线程,把服务器端套接字的描述发给客户端,一旦客户端确认了此描述,双方就正式建立连接,而服务器端的套接字继续处于监听状态,继续接受其它客户端套接字的连接请求;

HTTP的 URL 的一般形式是: http://<主机>:<端口>/<路径>

HTTP 的默认端口号是:80;

HTTP 有两类报文:

1请求报文---从客户端向服务器发送的请求报文

2响应报文---从服务器到客户的回答

特点:所有的请求参数都拼接都 URL 的后面;

缺点:

特点:

1xx 保留响应保留;

2xx 请求成功接收;

3xx 为完成请求客户端需要进一步细化请求;

4xx 客户端请求错误(参数,方式不正确);

5xx 服务器端有错误;

苹果产品在网吧进行降级操作是可行的，但是需要注意，在网吧进行降级操作需要使用电脑，而网吧的电脑可能会存在各种不可控因素导致降级操作失败或造成其他后果。因此，建议在网吧进行降级操作时，选择可信任的电脑或自行携带笔记本电脑以保证降级过程的顺利进行。

线程间通讯方式：

共享内存（静态对象之类的）

tcp

文件

进程间通讯方式：

共享内存

tcp

文件

管道(pipe，什么双开，半开。。。)

苹果手机服务器连接的具体方法如下：

首先点击桌面上的“设置”图标进入设置选项。

然后再设置选项中点击“通用”按钮进入通用设置中。

再通用设置汇总找到“***”按钮并点击进入***设置。

然后再点击添加***设置进行设置。

进入苹果官网找到***客服并咨询。

最后再选择并连接即可连接苹果服务器。

    很多苹果FGO国服的玩家都会遇到服务器通讯被中断的问题，这是由于玩家手机是ios10的缘故，那么到底应该怎么解决这个问题呢？下面我们就来看下具体方法。

手机设备已升级至iOS 10的用户，请按以下步骤， 确认是否已打开《命运-冠位指定》的网络访问权限 ，以避免可能会因此导致的无法登录游戏的情况。

操作步骤：

1 进入“设置”界面

2 向下滑动，找到《命运-冠位指定》应用，并点击进入

3 点击“无线数据”

4 选择“无线局域网与蜂窝移动数据”

5 完成设置，正常返回即可

    值得注意的一点是fgo服务器通讯中断只出现在ios10的系统，所以不是该系统的玩家不用担心这个问题啦！

现在市面上基于 usbmuxd 协议软件已经有很多，比如通过三方软件读取ios设备相册，安装、卸载软件，peertalk等，大部分通信协议为plist。流程为：

mac <-> usbmuxd <-> ios <-> lockdownd <-> service

ios-webkit-debug-proxy 作为较为人熟知的框架也是通过这种方式，比较特殊的是通信协议变为了二进制的plist，也就是bplist，可以使用 plistutil 实现和xml互转。

再进一步呢？

比如腾讯的wetest开发的PerfDog， 实现跨平台获取非越狱设备的性能数据，实现和xcode中开发功能通信，方便自动化获取instrument数据。

本文借助 ios-webkit-debug-proxy 源码来了解mac 和 ios 指定服务通信原理。

定位到 ios-webkit-debug-proxy -> webinspector

int wi_connect(const char device_id, char to_device_id, char to_device_name, int to_device_os_version, void to_ssl_session, int recv_timeout)

本人初衷是为了破解XCTest 通信协议，但是在实现过程中发现并不能通过 lockdownd_start_service 直接把手机指定服务启动成功。看来如果想要破解XCTest协议，还需要多一步，先了解xcode通信的内容。

启动失败：

启动成功（安装ipa服务）：

到现在为止，并未成功模拟xcode启动xctest流程，不知道哪里的问题，忘有看到此文章的大佬不吝指教。