（1）TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接；
（2）TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保 证可靠交付；
（3）TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）；
（4）每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信；
（5）TCP首部开销20字节;UDP的首部开销小，只有8个字节；
（6）TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。
（1）保证能够接收到最后一个ack；
（2）被动关闭的一方可能还有一些数据包没有被主动关闭的一方接收到，因此主动关闭的一方会继续占用端口，接收这些数据包。
（3）加问：为什么还会有数据包没有被接收呢？因为这些被动断开方发送的数据包可能后于其发送的 FIN 到达，只要还没close，在 TIME_WAIT-CLOES 这段时间内可以继续接收数据包。
Client 会在发送出 ACK 之后进入到 TIME_WAIT 状态。Client 会设置一个计时器，等待 2MSL 的时间。如果在该时间内再次收到 FIN，那么 Client 会重发 ACK 并再次等待 2MSL。
所谓的 2MSL 是两倍的 MSL(Maximum Segment Lifetime)。MSL 指一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束TCP 连接。
对于客户端，处于 syn_sent，等待确认包 syn+ack，当然是超时重发 ack。分别间隔 6s、24s 后重发，之后会放弃连接。
对于客户端，处于 syn_sent，等待确认包 syn+ack，当然是超时重发 ack。
对于服务端，处于 syn_recv，等待确认报 ack，当然是超时重发 syn+ack，如果重发几次仍然无用，则主动关闭连接，进入closed 状态。
第三次握手是客户端给服务端发送一个 ack，确认客户端第二次握手时发送的 syn+ack。
对于服务端，连接状态为 syn_recv，如果该ack丢失，服务端一直接收不到ack，会依次等待 3s、6s、12s 重发 syn+ack，重发指定次数后，server 会主动关闭这个链接。然后呢？是如何主动关闭的？
Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5。
对于客户端，连接状态为 established，它认为已经建立好连接，可以发送数据。当 client 发送数据给 server 时，server 会发送 rst，重新开始建立连接的过程。
不行，两次握手不可靠。如果建立连接时，syn 由于网络拥塞等原因没有发送到 server 端，client 端会重发 syn，如果之后建立了连接，发送了数据，然后关闭了连接。网络中还有没有 syn，会再次建立连接，服务端保持着连接而没有数据收到，造成资源浪费。在存在高并发的场景，会造成更大的资源浪费。
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
四次握手建立连接的时延大，效率低。三次握手已经可以保证可靠性。
在断开连接的时候，server 把响应客户端的请求 ACK 和断开请求 FIN 放在一起发送给 client 了，即第二次挥手时有FIN+ACK。
然而，一个方向的断开，只是说明该方向数据已传输完毕，而另一个方向或许还有数据，所以得等到另一个方向数据也全部传输完成后，才能执行第三次挥手发送 FIN。
建立连接时，三次握手即可以完成可靠连接，因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
关闭连接时，当Server端收到FIN报文时，很可能还有数据报文没有发送完毕，因此并不会立即关闭SOCKET，只能先回复一个ACK报文，对 client 端的单向断开进行确认。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
TCP还设有一个保活计时器。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
首先，A向B发送SYN，同时B向A发送SYN报文。A和B收到报文后，向对方发送SYN+ACK，再收到对方发来的SYN+ACK后，将恢复一个ACK，此时连接建立。每一端发送的SYN与SYN+ACK报文的Seq一样。
每一端都认为自己发送的第一个SYN是无用的（其实对对方来说是有用的），之后，双方都认为对方是主动方。双方都经历了SYN_SENT、SYN_RECV、ESTABLISHED。
TCP 协议也允许同时关闭。同时发送 FIN 包，两端同时执行主动关闭，进入 FIN_WAIT_1 的状态，从 FIN_WAIT_1 状态收到 FIN 包的时候进入 CLOSING 状态，然后回复 ACK，进入 TIME_WAIT 状态。
双方都认为自己是主动关闭的一方，因此，双方都经历了 FIN_WAIT_1、CLOSING、TIME_WAIT。
（1）CLOSED：
初始状态，表示TCP连接是关闭或者未打开
（2）LISTEN：
表示服务端的某个socket处于监听状态，可以接受客户端的连接
（3）SYN_RCVD:
表示收到了SYN报文。这个状态基本上是服务器端收到SYN报文后的一个短暂的中间状态，使用netart很难捕捉到。当再次收到客户端的ACK报文时，进入到ESTABLISHED的状态。
（4）SYN_SENT
这个状态与SYN_RCVD状态相呼应，客户端主动发起连接，调用connect函数时，发送SYN报文，随即进入到SYN_SENT状态，并等待服务端的SYN报文。当接收到服务端的SYN报文后，回应ACK后，会进入到 ESTABLISHED 的状态。
（5）ESTABLISHED
表示TCP已经建立成功。
（6）FIN_WAIT_1
这个状态得好好解释一下，其实FIN_WAIT_1 和FIN_WAIT_2 两种状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET进入到FIN_WAIT_1 状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2 状态。当然在实际的正常情况下，无论对方处于任何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1 状态一般是比较难见到的，而FIN_WAIT_2 状态有时仍可以用netstat看到.
（7）FIN_WAIT_2：
上面已经解释了这种状态的由来，实际上FIN_WAIT_2状态下的SOCKET表示半连接，即有一方调用close()主动要求关闭连接。注意：FIN_WAIT_2 是没有超时的（不像TIME_WAIT 状态），这种状态下如果对方不关闭（不配合完成4次挥手过程），那这个 FIN_WAIT_2 状态将一直保持到系统重启，越来越多的FIN_WAIT_2 状态会导致内核crash。
（8）TIME_WAIT
表示收到了对方的FIN报文，并且已经发送了ACK。这个时候实际上已经没有了报文交互，那么TIME_WAIT状态下的TCP连接会等待2*MSL，然后回到CLOSE状态。（Max Segment Lifetime，最大分段生存期，指一个TCP报文在Internet上的最长生存时间。每个具体的TCP协议实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟，但BSD传统实现采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值）。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态
（9）CLOSING
CLOSING 状态表示一方发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。
什么情况下会出现此种情况呢？那就是当双方几乎在同时close()一个SOCKET的话，就出现了双方同时发送FIN报文的情况，这是就会出现CLOSING 状态，表示双方都正在关闭SOCKET连接。这种状态在实际情况中应该很少见，属于一种比较罕见的例外状态。正常情况下，当一方发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。
（10）CLOSE_WAIT
表示正在等待关闭。怎么理解呢？当对方close()一个SOCKET后发送FIN报文给自己，你的系统毫无疑问地将会回应一个ACK报文给对方，此时TCP连接则进入到CLOSE_WAIT状态。接下来呢，你需要检查自己是否还有数据要发送给对方，如果没有的话，那你也就可以close()这个SOCKET并发送FIN报文给对方，即关闭自己到对方这个方向的连接。有数据的话则看程序的策略，继续发送或丢弃。简单地说，当你处于CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。加入对方一直不回应ACK报文，则socket会一直无法关闭。
（11）LAST_ACK
当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK 状态。当收到对方的ACK报文后，也就可以进入到CLOSED 状态了。
proto://url:port/path
proto://user:passwd@url:port/path
4、socket服务端的实现，select和epoll的区别？
(1) select缺点:
1.最大并发数限制：使用32个整数的32位，即32*32=1024来标识fd，虽然可修改，但是有以下第二点的瓶颈；
2.效率低：每次都会线性扫描整个fd_set，集合越大速度越慢；
3.内核/用户空间内存拷贝问题。
(2) epoll的提升：
1.本身没有最大并发连接的限制，仅受系统中进程能打开的最大文件数目限制；
2.效率提升：只有活跃的socket才会主动的去调用callback函数；
3.省去不必要的内存拷贝：epoll通过内核与用户空间mmap同一块内存实现。
5、epoll哪些触发模式，有啥区别？
(1) epoll 两种工作模式
水平触发：
内核中的socket接收缓冲区不为空，有数据可读，读事件一直触发
内核中的socket发送缓冲区不满，可以继续写入数据，写事件一直触发
边缘触发：
内核中socket接收缓冲区由空变为不为空，数据由不可读变为可读，事件触发（仅一次）。
内核中socket发送缓冲区由满变为不满，数据由不可写变为可写，事件触发（仅一次）。
(2) 工作模式选择时候，LT模式会一直触发可读可写事件，导致效率比较低。ET模式由于读写事件
仅通知一次，可能会存在数据丢失的可能。
(3) 1.ET模式时，当有多个连接同时到达服务器，epoll_wait会返回多个描述符，由于在ET模式下就绪状态只返回一次，
因此为了防止漏掉连接，需要循环调用accept直到接收全部连接（即返回EAGAIN错误）。
2. ET模式时，在读写数据时，同样需要注意读写事件只触发一次的问题，若一次读或写没有处理全部数据，
则会导致数据丢失。解决办法是，accept接收连接时，设置连接的套接字为非阻塞，
并在读写数据时循环调用read/write直到数据全部处理为止（即返回EAGAIN错误）。
3. LT模式时，若监控epoll out事件，由于内核缓冲区一开始时一直处于可写状态，会导致epoll_wait一直返回，降低效率。解决办法，
一开始不监听out事件，直接写数据直到写缓冲区满时（即返回EAGAIN错误），再监听out事件，当数据全部写完时，就取消对out事件的监听
6、大规模连接上来，并发模型怎么设计？(高并发网络模型)
(1) Linux的并发模型有三种，包括：多进程并发、多线程并发以及IO复用模型。
(2)多进程并发：accept返回成功时候，就为这一个连接fork一个进程，专门处理这个连接上的数据收发，等这个连接处理结束之后就结束这个进程
所线程并发：类似多进程方式，但是针对一个连接启动一个线程。
优点： 相对多进程方式，会节约一些资源，会更加高效一些。
缺点： 相对多进程方式，增加了编程的复杂度，因为需要考虑数据同步和锁保护。另外一个进程中不能启动太多的线程。
在Linux系统下线程在系统内部其实就是进程，线程调度按照进程调度的方式去执行的
Select+多线程：有一个线程专门用于监听端口，accept返回之后就把这个描述符放入 描述符集合 fd中，一个线程用select去轮训描述符集合，
在有数据的连接上接收数据，另外一个线程专门发送数据。当然也可以接收和发送用一个线程。
epoll方式：一个线程专门进行端口监听，accept接收到连接的时候，把该连接设置成非阻塞模式，
把 epoll事件设置成边缘触发方式，加入到epoll管理。接收线程阻塞在epoll的等待事件函数。另外一个线程专门用于数据发送.
7、tcp结束连接怎么握手，time_wait状态是什么,为什么会有time_wait状态？哪一方会有time_wait状态，如何避免time_wait状态占用资源？
tcp通过四次挥手结束连接。
TIME_WAIT: 表示收到了对方的FIN报文，并且已经发送了ACK。这个时候实际上已经没有了报文交互，那么TIME_WAIT状态
下的TCP连接会等待2*MSL，然后回到CLOSE状态。（Max Segment Lifetime，最大分段生存期，
指一个TCP报文在Internet上的最长生存时间。每个具体的TCP协议实现都必须选择一个确定的MSL值，
RFC 1122建议是2分钟，但BSD传统实现采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值）。
如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
TIME_WAIT状态是发起断连的一端存在的状态。
TIME_WAIT状态存在的意义：1、实现可靠的全双工连接：因为在最后一次发送ACK报本可能丢失，则对端可能会希望本端复位重发，导致错误产生。
2、允许老的重复的分段在网络上消失。
8、tcp头多少字节？哪些字段?
tcp头有20字节，包括选项时会增大，最大不超过60字节。包括：16位源端口号、16位目的端口号、32位的序号、32位确认号、4位头部长度
标志位、16位窗口大小、16位校验和、16位紧急指针。
9、什么是滑动窗口？(后续补充)
TCP协议里窗口机制有2种：一种是固定的窗口大小；一种是滑动的窗口。这个窗口大小就是我们一次传输几个数据。
对所有数据帧按顺序赋予编号，发送方在发送过程中始终保持着一个发送窗口，只有落在发送窗口内的帧才允许被发送；
同时接收方也维持着一个接收窗口，只有落在接收窗口内的帧才允许接收。这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制。
TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。
10、connect会阻塞，怎么解决?
connect调用的时候，当发起主动连接的时候，如果服务端关闭，则进程会被connect阻塞，等待较长时间返回。假如直接将connect直接定义
为非阻塞的，则无法确定connect是否连接成功。
1．建立socket
2．将该socket设置为非阻塞模式
3．调用connect()
4．使用select()检查该socket描述符是否可写
5．根据select()返回的结果判断connect()结果
6．将socket设置为阻塞模式
11、如果select返回可读，结果只读到0字节，什么情况？
之前处理过这么一个问题，就是socket一直返回可读，导致任务死循环。这个问题最后的结果是因为socket发生错误，但是没有读取错误码
导致socket一直可读。
12、keepalive 是什么东东？如何使用？
TCP协议中有长连接和短连接之分。短连接在数据包发送完毕后就会自己断开，长连接在发包完毕后，会在一定的时间内保持连接，即通常所说的
keepalive功能。
当tcp检测到对端socket不再可用时(不能发出探测包,或探测包没有收到ACK的响应包),select会返回socket可读,并且在recv时返回-1,
同时置上errno为ETIMEDOUT。此时TCP的状态是断开的。
13、列举你所知道的tcp选项，并说明其作用？
14、socket什么情况下可读？
下列四个条件中的任何一个满足时,socket准备好读:
1.socket接收缓冲区中已经接收的数据的字节数大于等于socket接收缓冲区低潮限度的当前值;
对这样的socket的读操作不会阻塞,并返回一个大于0的值(即:准备好读入的数据的字节数).
我们可以用socket选项SO_RCVLOWAT来设置此低潮限度,对于TCP和UDPsocket,其缺省值为1;
2.连接的读这一半关闭(即:接收到对方发过来的FIN的TCP连接).对于这样的socket的读操作将不阻塞,
并且返回0(即:文件结束符,FIN包体长度为0字节);
3.socket是一个用于监听的socket,并且已经完成的连接数为非0.这样的soocket处于可读状态,
是因为socket收到了对方的connect请求,执行了三次握手的第一步:对方发送SYN请求过来,使监听socket处于可读状态;正常情况下,
这样的socket上的accept操作不会阻塞;
4.有一个socket有异常错误条件待处理.对于这样的socket的读操作将不会阻塞,并且返回一个错误(-1),errno则设置成明确的错误条件.
这些待处理的错误也可通过指定socket选项SO_ERROR调用getsockopt来取得并清除;
下列三个条件中的任何一个满足时,socket准备好写 :
1.socket发送缓冲区中的可用空间字节数大于等于socket发送缓冲区低潮限度的当前值,且(i):socket已连接(TCP socket),
或者(ii):socket不要求连接(如:UDP socket).这意味着,如果我们将这样的socket设置为非阻塞模式,写操作将不会阻塞,并且返回一个正值
(如:由传输层接收的字节数).我们可以用socket选项SO_SNDLOWAT来设置此低潮限度,对于TCP和UDP socket,其缺省值一般是2048Bytes;
2.连接的写这一半关闭.对于这样的socket的的写操作将产生信号SIGPIPE;
3.有一个socket异常错误条件待处理.对于这样的socket的写操作将不会阻塞并且返回一个错误(-1),errno则设置成明确的错误条件.
这些待处理的错误也可以通过指定socket选项SO_ERROR调用getsockopt函数来取得并清除;