1、HTTP连接
HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。
HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。
1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。
1、TCP连接
手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接。TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在“无差别”的网络之上。
建立起一个TCP连接需要经过“三次握手”：
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）
面向连接的传输协议:
我们首先知道TCP是面向连接的，它的意思是说两个远程主机（或者叫进程，因为实际上远程通信是进程之间的通信，而进程则是运行中的程序），必须首先进行一个握手过程，确认连接成功，之后才能传输实际的数据。比如说进程A想将字符串“It's a fine day today”发给进程B，它首先要建立连接。在这一过程中，它首先需要知道进程B的位置（主机地址和端口号）。随后发送一个不包含实际数据的请求报文，我们可以将这个报文称之为“hello”。如果进程B接收到了这个“hello”，就向进程A回复一个“hello”，进程A随后才发送实际的数据“It's a fine day today”。
关于TCP第二个需要了解的，就是它是全双工的。意思是说如果两个主机上的进程（比如进程A、进程B），一旦建立好连接，那么数据就既可以由A流向B，也可以由B流向A。除此以外，它还是点对点的，意思是说一个TCP连接总是两者之间的，在发送中，通过一个连接将数据发给多个接收方是不可能的。TCP还有一个特性，就是称为可靠的数据传输，意思是连接建立后，数据的发送一定能够到达，并且是有序的，就是说发的时候你发了ABC，那么收的一方收到的也一定是ABC，而不会是BCA或者别的什么。
2.关于数据流
Stream在msdn的定义：提供字节序列的一般性视图（provides a generic view of a sequence of bytes）。这个解释太抽象了，不容易理解；从stream的字面意思“河，水流”更容易理解些，stream是一个抽象类，它定义了类似“水流”的事物的一些统一行为，包括这个“水流”是否可以抽水出来（读取流内容）；是否可以往这个“水流”中注水（向流中写入内容）；以及这个“水流”有多长；如何关闭“水流”，如何向“水流”中注水，如何从“水流”中抽水等“水流”共有的行为。
常用的Stream的子类有：
1） MemoryStream 存储在内存中的字节流
2） FileStream 存储在文件系统的字节流
3） NetworkStream 通过网络设备读写的字节流
4） BufferedStream 为其他流提供缓冲的流
Stream提供了读写流的方法是以字节的形式从流中读取内容。而我们经常会用到从字节流中读取文本或者写入文本，微软提供了StreamReader和StreamWriter类帮我们实现在流上读写字符串的功能。
3.1套接字（socket）概念
套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
3.2 建立socket连接
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。
套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
4.套接字Socket:
编程中与TCP相关的最重要的一个概念就是套接字。我们应该知道网络七层协议，如果我们将上面的应用程、表示层、会话层笼统地算作一层（有的教材便是如此划分的），那么我们编写的网络应用程序就位于应用层，而大家知道TCP是属于传输层的协议，那么我们在应用层如何使用传输层的服务呢（消息发送或者文件上传下载）？大家知道在应用程序中我们用接口来分离实现，在应用层和传输层之间，则是使用套接字来进行分离。它就像是传输层为应用层开的一个小口，应用程序通过这个小口向远程发送数据，或者接收远程发来的数据；而这个小口以内，也就是数据进入这个口之后，或者数据从这个口出来之前，我们是不知道也不需要知道的，我们也不会关心它如何传输，这属于网络其它层次的工作。
OSI的7层从上到下分别是 7 应用层 6 表示层 5 会话层 4 传输层 3 网络层 2 数据链路层 1 物理层 ；其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流。
5.一种架构是Peer-to-Peer 对等通信结构，如下图所示，即在多个玩家参与的游戏中，各玩家之间采用Peer-to-Peer的直接通信方式。在网络通信服务的形式上，一般采用浮动服务器的形式，即其中一个玩家的机器既是客户端，又扮演服务器的角色，一般由创建游戏局的玩家担任服务器（主机）。很多对战型的RTS网络游戏都采用这种结构。

优点:
延时较小。延时就是指信息在从发出到接收这个过程中所用的传输时间。在C/S模式中，信息是先从一个客户端传到服务器端，而后再从服务器端传到另一个客户端。但P2P架构则是让信息直接在两个客户端间传递，这样就比C/S模式减少了一半的传递时间。
不需要服务器端。既然P2P架构全是由客户端建成的，因此也就没必要使用服务器端。这对于无论是游戏开发者还是发布者来说都是一件好事，因为他们不用再为维持运行游戏中央服务器而支付主机托管和管理费了。
缺点
游戏的可扩展性差。当游戏的客户端相当少的时候，那就用P2P吧，因为它产生的延时很小且不需要使用服务器端。但是当游戏有很多客户端时，比如说成百或上千个客户端，那么P2P架构就不适用了。因为它需要每个客户端都和其他客户端保持一个独立的连接。那么如果有1000个客户端的话，完整拓扑架构就要求每一个客户端都要建立并维持1000个开放的连接，其中每一个客户端都要接受来自其他客户端发出的所有信息。而在C/S架构中，一个客户端只从服务器端接受经其职能筛选和归集后的信息。
另外，还要考虑一下此种网络的应用环境。假设你有1000个客户端，但是它们全都在学校的子网络中，1000个用户彼此相连导致产生了1000000个连接，这将会使网络因不堪重负而瘫痪。但是如果同样数目的连接放到全球互联网上，则根本不会出任何问题。
争议解决机制不健全。假如有个双人P2P游戏，每一方都能操纵鼠标去吃奶酪。玩家A接近第一块奶酪，然后确定离它足够近时就可以吃了它，于是玩家A因为吃了奶酪而获得了一定的积分，然后他传递信息给玩家B，告诉B：这块奶酪已经被我吃了。玩家B接收并处理了这条信息后从自己的屏幕上删除了那块奶酪，并且更新了玩家A的得分。谁都没有异议，两个客户端对当前游戏的状态达成了一致。
但比如说现在玩家A和玩家B都在对下一块奶酪跃跃欲试。不巧的是这一次他们相互之间逻辑决策的时间就差了几毫秒，双方都各自认定是自己吃了这块奶酪，然后都给自己加上了分，然后互发信息给对方证明是自己把奶酪吃了。结果两个玩家就会互不相让。
所以，P2P架构的一个缺点就是：没有中心逻辑决策者。
6关于序列化及反序列化
.net的运行时环境用来支持用户定义类型的流化的机制。它是将对象实例的状态存储到存储媒体的过程。在此过程中，先将对象的公共字段和私有字段以及类的名称（包括类所在的程序集）转换为字节流，然后再把字节流写入数据流。在随后对对象进行反序列化时，将创建出与原对象完全相同的副本。
6.1序列化的目的
1、以某种存储形式使自定义对象持久化；
2、将对象从一个地方传递到另一个地方。
6.2关于Json
什么是 JSON ？
JSON 指的是 JavaScript 对象表示法（JavaScript Object Notation）
JSON 是轻量级的文本数据交换格式
JSON 独立于语言 *
JSON 具有自我描述性，更易理解
* JSON 使用 JavaScript 语法来描述数据对象，但是 JSON 仍然独立于语言和平台。JSON 解析器和 JSON 库支持许多不同的编程语言。
using LitJson;
using System;
public class Person
{
string Name;
string Age;
string Birthday;
}
public class JsonSample
{
public static void Main ()
{
PersonToJson ();
JsonToPerson ();
}
public static void PersonToJson ()
{
Person bill = new Person ();
bill.Name = "William Shakespeare";
bill.Age = 51;
bill.Birthday = new DateTime (1564, 4, 26);
string json_bill = JsonMapper.ToJson (bill);
Console.WriteLine (json_bill);
// {"Name":"William Shakespeare","Age":51,"Birthday":"04/26/1564 00:00:00"}
}
public static void JsonToPerson ()
{
string json = @"
{
""Name"" : ""Thomas More"",
""Age"" : 57,
""Birthday"" : ""02/07/1478 00:00:00""
}";
Person thomas = JsonMapper.ToObject<Person> (json);
Console.WriteLine ("Thomas' age: {0}", thomas.Age);
// Thomas' age: 57
}
}
7.关于心跳包
心跳包的发送，通常有两种技术
方法1：应用层自己实现的心跳包
由应用程序自己发送心跳包来检测连接是否正常，大致的方法是：服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包，然后启动一个低级别的线程，在该线程中不断检测客户端的回应， 如果在一定时间内没有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没 有收到服务器的心跳包，则认为连接不可用。
方法2：TCP的KeepAlive保活机制
因为要考虑到一个服务器通常会连接多个客户端，因此由用户在应用层自己实现心跳包，代码较多 且稍显复杂，而利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。 不论是服务端还是客户端，一方开启KeepAlive功能后，就会自动在规定时间内向对方发送心跳包， 而另一方在收到心跳包后就会自动回复，以告诉对方我仍然在线。 因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不开启KeepAlive功 能，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，KeepAlive设置不合理时可能会 因为短暂的网络波动而断开健康的TCP连接。并且，默认的KeepAlive超时需要7,200，000 MilliSeconds， 即2小时，探测次数为5次。对于很多服务端应用程序来说，2小时的空闲时间太长。因此，我们需要手工开启KeepAlive功能并设置合理的KeepAlive参数。
7.1为什么要叫做心跳包
跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。
总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。
7.2心跳包检测步骤
客户端每隔一个时间间隔发生一个探测包给服务器
2客户端发包时启动一个超时定时器
3服务器端接收到检测包，应该回应一个包
4如果客户机收到服务器的应答包，则说明服务器正常，删除超时定时器
5如果客户端的超时定时器超时，依然没有收到应答包，则说明服务器挂了
HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。
HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。
1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。
1、TCP连接
手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接。TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在“无差别”的网络之上。
建立起一个TCP连接需要经过“三次握手”：
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）
面向连接的传输协议:
我们首先知道TCP是面向连接的，它的意思是说两个远程主机（或者叫进程，因为实际上远程通信是进程之间的通信，而进程则是运行中的程序），必须首先进行一个握手过程，确认连接成功，之后才能传输实际的数据。比如说进程A想将字符串“It's a fine day today”发给进程B，它首先要建立连接。在这一过程中，它首先需要知道进程B的位置（主机地址和端口号）。随后发送一个不包含实际数据的请求报文，我们可以将这个报文称之为“hello”。如果进程B接收到了这个“hello”，就向进程A回复一个“hello”，进程A随后才发送实际的数据“It's a fine day today”。
关于TCP第二个需要了解的，就是它是全双工的。意思是说如果两个主机上的进程（比如进程A、进程B），一旦建立好连接，那么数据就既可以由A流向B，也可以由B流向A。除此以外，它还是点对点的，意思是说一个TCP连接总是两者之间的，在发送中，通过一个连接将数据发给多个接收方是不可能的。TCP还有一个特性，就是称为可靠的数据传输，意思是连接建立后，数据的发送一定能够到达，并且是有序的，就是说发的时候你发了ABC，那么收的一方收到的也一定是ABC，而不会是BCA或者别的什么。
2.关于数据流
Stream在msdn的定义：提供字节序列的一般性视图（provides a generic view of a sequence of bytes）。这个解释太抽象了，不容易理解；从stream的字面意思“河，水流”更容易理解些，stream是一个抽象类，它定义了类似“水流”的事物的一些统一行为，包括这个“水流”是否可以抽水出来（读取流内容）；是否可以往这个“水流”中注水（向流中写入内容）；以及这个“水流”有多长；如何关闭“水流”，如何向“水流”中注水，如何从“水流”中抽水等“水流”共有的行为。
常用的Stream的子类有：
1） MemoryStream 存储在内存中的字节流
2） FileStream 存储在文件系统的字节流
3） NetworkStream 通过网络设备读写的字节流
4） BufferedStream 为其他流提供缓冲的流
Stream提供了读写流的方法是以字节的形式从流中读取内容。而我们经常会用到从字节流中读取文本或者写入文本，微软提供了StreamReader和StreamWriter类帮我们实现在流上读写字符串的功能。
3.1套接字（socket）概念
套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
3.2 建立socket连接
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。
套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
4.套接字Socket:
编程中与TCP相关的最重要的一个概念就是套接字。我们应该知道网络七层协议，如果我们将上面的应用程、表示层、会话层笼统地算作一层（有的教材便是如此划分的），那么我们编写的网络应用程序就位于应用层，而大家知道TCP是属于传输层的协议，那么我们在应用层如何使用传输层的服务呢（消息发送或者文件上传下载）？大家知道在应用程序中我们用接口来分离实现，在应用层和传输层之间，则是使用套接字来进行分离。它就像是传输层为应用层开的一个小口，应用程序通过这个小口向远程发送数据，或者接收远程发来的数据；而这个小口以内，也就是数据进入这个口之后，或者数据从这个口出来之前，我们是不知道也不需要知道的，我们也不会关心它如何传输，这属于网络其它层次的工作。
OSI的7层从上到下分别是 7 应用层 6 表示层 5 会话层 4 传输层 3 网络层 2 数据链路层 1 物理层 ；其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流。
5.一种架构是Peer-to-Peer 对等通信结构，如下图所示，即在多个玩家参与的游戏中，各玩家之间采用Peer-to-Peer的直接通信方式。在网络通信服务的形式上，一般采用浮动服务器的形式，即其中一个玩家的机器既是客户端，又扮演服务器的角色，一般由创建游戏局的玩家担任服务器（主机）。很多对战型的RTS网络游戏都采用这种结构。

优点:
延时较小。延时就是指信息在从发出到接收这个过程中所用的传输时间。在C/S模式中，信息是先从一个客户端传到服务器端，而后再从服务器端传到另一个客户端。但P2P架构则是让信息直接在两个客户端间传递，这样就比C/S模式减少了一半的传递时间。
不需要服务器端。既然P2P架构全是由客户端建成的，因此也就没必要使用服务器端。这对于无论是游戏开发者还是发布者来说都是一件好事，因为他们不用再为维持运行游戏中央服务器而支付主机托管和管理费了。
缺点
游戏的可扩展性差。当游戏的客户端相当少的时候，那就用P2P吧，因为它产生的延时很小且不需要使用服务器端。但是当游戏有很多客户端时，比如说成百或上千个客户端，那么P2P架构就不适用了。因为它需要每个客户端都和其他客户端保持一个独立的连接。那么如果有1000个客户端的话，完整拓扑架构就要求每一个客户端都要建立并维持1000个开放的连接，其中每一个客户端都要接受来自其他客户端发出的所有信息。而在C/S架构中，一个客户端只从服务器端接受经其职能筛选和归集后的信息。
另外，还要考虑一下此种网络的应用环境。假设你有1000个客户端，但是它们全都在学校的子网络中，1000个用户彼此相连导致产生了1000000个连接，这将会使网络因不堪重负而瘫痪。但是如果同样数目的连接放到全球互联网上，则根本不会出任何问题。
争议解决机制不健全。假如有个双人P2P游戏，每一方都能操纵鼠标去吃奶酪。玩家A接近第一块奶酪，然后确定离它足够近时就可以吃了它，于是玩家A因为吃了奶酪而获得了一定的积分，然后他传递信息给玩家B，告诉B：这块奶酪已经被我吃了。玩家B接收并处理了这条信息后从自己的屏幕上删除了那块奶酪，并且更新了玩家A的得分。谁都没有异议，两个客户端对当前游戏的状态达成了一致。
但比如说现在玩家A和玩家B都在对下一块奶酪跃跃欲试。不巧的是这一次他们相互之间逻辑决策的时间就差了几毫秒，双方都各自认定是自己吃了这块奶酪，然后都给自己加上了分，然后互发信息给对方证明是自己把奶酪吃了。结果两个玩家就会互不相让。
所以，P2P架构的一个缺点就是：没有中心逻辑决策者。
6关于序列化及反序列化
.net的运行时环境用来支持用户定义类型的流化的机制。它是将对象实例的状态存储到存储媒体的过程。在此过程中，先将对象的公共字段和私有字段以及类的名称（包括类所在的程序集）转换为字节流，然后再把字节流写入数据流。在随后对对象进行反序列化时，将创建出与原对象完全相同的副本。
6.1序列化的目的
1、以某种存储形式使自定义对象持久化；
2、将对象从一个地方传递到另一个地方。
6.2关于Json
什么是 JSON ？
JSON 指的是 JavaScript 对象表示法（JavaScript Object Notation）
JSON 是轻量级的文本数据交换格式
JSON 独立于语言 *
JSON 具有自我描述性，更易理解
* JSON 使用 JavaScript 语法来描述数据对象，但是 JSON 仍然独立于语言和平台。JSON 解析器和 JSON 库支持许多不同的编程语言。
using LitJson;
using System;
public class Person
{
string Name;
string Age;
string Birthday;
}
public class JsonSample
{
public static void Main ()
{
PersonToJson ();
JsonToPerson ();
}
public static void PersonToJson ()
{
Person bill = new Person ();
bill.Name = "William Shakespeare";
bill.Age = 51;
bill.Birthday = new DateTime (1564, 4, 26);
string json_bill = JsonMapper.ToJson (bill);
Console.WriteLine (json_bill);
// {"Name":"William Shakespeare","Age":51,"Birthday":"04/26/1564 00:00:00"}
}
public static void JsonToPerson ()
{
string json = @"
{
""Name"" : ""Thomas More"",
""Age"" : 57,
""Birthday"" : ""02/07/1478 00:00:00""
}";
Person thomas = JsonMapper.ToObject<Person> (json);
Console.WriteLine ("Thomas' age: {0}", thomas.Age);
// Thomas' age: 57
}
}
7.关于心跳包
心跳包的发送，通常有两种技术
方法1：应用层自己实现的心跳包
由应用程序自己发送心跳包来检测连接是否正常，大致的方法是：服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包，然后启动一个低级别的线程，在该线程中不断检测客户端的回应， 如果在一定时间内没有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没 有收到服务器的心跳包，则认为连接不可用。
方法2：TCP的KeepAlive保活机制
因为要考虑到一个服务器通常会连接多个客户端，因此由用户在应用层自己实现心跳包，代码较多 且稍显复杂，而利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。 不论是服务端还是客户端，一方开启KeepAlive功能后，就会自动在规定时间内向对方发送心跳包， 而另一方在收到心跳包后就会自动回复，以告诉对方我仍然在线。 因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不开启KeepAlive功 能，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，KeepAlive设置不合理时可能会 因为短暂的网络波动而断开健康的TCP连接。并且，默认的KeepAlive超时需要7,200，000 MilliSeconds， 即2小时，探测次数为5次。对于很多服务端应用程序来说，2小时的空闲时间太长。因此，我们需要手工开启KeepAlive功能并设置合理的KeepAlive参数。
7.1为什么要叫做心跳包
跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。
总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。
7.2心跳包检测步骤
客户端每隔一个时间间隔发生一个探测包给服务器
2客户端发包时启动一个超时定时器
3服务器端接收到检测包，应该回应一个包
4如果客户机收到服务器的应答包，则说明服务器正常，删除超时定时器
5如果客户端的超时定时器超时，依然没有收到应答包，则说明服务器挂了
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
