学习

1 iOS开发-探索scrollView的实现

探索scrollView的实现

2 NSArray 为空导致 crash 的解决

• scrollView滚动实现的本质，基于自身的坐标系发生了位置偏移
• contentOffset决定了scrollView的窗口
• contentSize决定了scrollView显示内容的尺寸范围
• contentInset决定了偏移量可以增加或者减少我们的滚动尺寸范围

quick和nimble
specta库 用自然语言描述你在做什么 spect是描述测试的对象的
比如我描述是 NSNull的测试用例 it(它) 应该不会crash 当你给一个NSString类型发送消息的时候

这一句叫预期的结果 属于 expect库 学会了这个 你换任何语言都能干 expect是用来取代系统的assert expect只是封装了 自然语言化的 asert

OCMock 和 quick

每个spec都是建立一个啥东西，然后一通操作，然后 expect expect expect

3 重载与重写

override（重写）

　　 - 方法名、参数、返回值相同。
　　
　　 - 子类方法不能缩小父类方法的访问权限。
　　
　　 - 子类方法不能抛出比父类方法更多的异常(但子类方法可以不抛出异常)。
　　
　　 - 存在于父类和子类之间。
　　
　　 - 方法被定义为final不能被重写。
　　
　overload（重载）
　　 　
　　 - 参数类型、个数、顺序至少有一个不相同。
　　 　　　
　　 - 不能重载只有返回值不同的方法名。
　　 　　　　　
　　 - 存在于父类和子类、同类中。
　　

4 TCP/UDP区别以及UDP如何实现可靠传输TCP/UDP区别以及UDP如何实现可靠传输

TCP和UDP是OSI模型中的运输层中的协议。TCP提供可靠的通信传输，而UDP则常被用于让广播和细节控制交给应用的通信传输。

UDP(User Datagram Protocol)

UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。

即使是出现网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的行为。此外，传输途中如果出现了丢包，UDO也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正的功能。如果需要这些细节控制，那么不得不交给由采用UDO的应用程序去处理。换句话说，UDP将部分控制转移到应用程序去处理，自己却只提供作为传输层协议的最基本功能。UDP有点类似于用户说什么听什么的机制，但是需要用户充分考虑好上层协议类型并制作相应的应用程序。

TCP(Transmission Control Protocol)

TCP充分实现爱呢了数据传输时各种控制功能，可以进行丢包的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外，TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。

TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。此处不一一叙述。

TCP与UDP如何加以区分使用？

TCP用于在传输层有必要实现可靠性传输的情况。由于它是面向有连接并具备顺序控制、重发控制等机制的。所以它可以为应用提供可靠传输。

另一方面，UDP主要用于那些对高速传输和实时性有较高要求的通信或广播通信。举一个IP电话进行通话的例子。如果使用TCP，数据在传送途中如果丢失会被重发，但是这样无法流畅地传输通话人的声音，会导致无法进行正常交流。而采用UDP，它不会进行重发处理。从而也就不会有声音大幅度延迟到达的问题。即使有部分数据丢失，也只是影响某一小部分的通话。此外，在多播与广播通信中也使用UDP而不是UDP。RIP、DHCP等基于广播的协议也要依赖于UDP。

TCP与UDP区别总结：

1、TCP面向连接（如打电话要先拨号建立连接）;
UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;
UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;
UDP是面向报文的 UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、TCP连接只能是点到点的;
UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

UDP如何实现可靠传输

由于在传输层UDP已经是不可靠的连接，那就要在应用层自己实现一些保障可靠传输的机制

简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的

超时重传（定时器）

有序接受 （添加包序号）

应答确认 （Seq/Ack应答机制）

滑动窗口流量控制等机制 （滑动窗口协议）

等于说要在传输层的上一层（或者直接在应用层）实现TCP协议的可靠数据传输机制，比如使用UDP数据包+序列号，UDP数据包+时间戳等方法。

目前已经有一些实现UDP可靠传输的机制，比如

UDT（UDP-based Data Transfer Protocol）
基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。 顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。 由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。+

5 TCP的流量控制与拥塞控制小结 https://blog.csdn.net/u014774781/article/details/48047977

为了提高信道的利用率TCP协议不使用停止等待协议，而是使用连续ARQ协议，意思就是可以连续发出若干个分组然后等待确认，而不是发送一个分组就停止并等待该分组的确认。其中TCP的流量控制与拥塞控制是TCP在数据传输过程俩个重点机制.

自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中运输层的错误纠正协议之一。它包括停止等待ARQ协议和连续ARQ协议，错误侦测（Error Detection）、正面确认（Positive Acknowledgment）、逾时重传（Retransmission after Timeout）与负面确认继以重传（Negative Acknowledgment and Retransmission）等机制.

1、流量控制
流量控制：指点对点通信量的控制，是端到端正的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

在TCP中的数据流主要分为俩大类：成块数据流和交互数据流，（其中交互数据流主要是数据字节长度比IP首部/TCP首部都短，属于小分组），主要针对这俩种数据流类型做了不同的处理

1.1、滑动窗口机制
主要针对成块数据流，利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
1.2 交互数据流的Nagle算法
Nagle更多的应该是提高传输效率，由于TCP的数据传输分为交互数据流和成块数据流，交互数据流一般是一些交互式应用程序的命令，所以这些数据很小，而考虑到TCP报头和IP报头的总和就有40字节，在局域网通常不会引起麻烦啊，但是在广域网上这些小分组往往会增加拥塞的可能性。

Nagle算法（针对小分组）：若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起 来。当发送方接收对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段再发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一 个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。

该算法的优越之处在于他的自适应性：确认到达越快，数据也发送的越快
2、拥塞控制
拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制.

• 快重传
• 快恢复
• 慢开始
• 拥塞避免

2.1、慢开始与拥塞避免
发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小，实时拥塞窗口大小是以字节为单位的

2.2、快重传和快恢复
快重传要求接收方收到一个失序的报文段之后就立即发出重复确认，而不要等到自己发送的数据时捎带确认。快重传 算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期（快体现在这里）
快速重传以后，因为走的不是慢启动而是拥塞避免算法，所以这又叫做快速恢复算法
主要有有以下两个要点:
①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

拥塞窗口cwnd（congestion window）
慢启动阈值ssthresh (slow start threshold)

6 socket编程的过程

服务器
- sockt() 建立流式套接字，返回套接字句柄
- bind() 关联本地地址与套接字
- listen() 设置backlog值，进入监听状态
- accept() 等待接受客户连接请求
- 建立连接，accept()函数返回，得到新的套接字
- recv()/send(),在新的套接字上收发数据，直到完成交换
- closesocket(),关闭新的套接字，服务结束

客户端
- sockt() 建立流式套接字，返回套接字句柄
- connect() 将套接字与服务器连接
- recv()/send(),在新的套接字上收发数据，直到完成交换
- closesocket(),关闭新的套接字，结束TCP对话

7 HTTP1.0 HTTP 1.1 HTTP 2.0主要区别

1 长连接

HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。

HTTP是基于TCP/IP协议的，创建一个TCP连接是需要经过三次握手的,有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接，可以用个长连接来发多个请求

2 节约带宽

HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。

这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。

另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。

3 HOST域 （HTTP1.1 HTTP 2.0主要区别）

现在可以设置虚拟站点web server，例如tomat。也就是说，web server上的多个虚拟站点可以共享同一个ip和端口。

HTTP1.0是没有host域的，HTTP1.1才支持这个参数。

4 多路复用

HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

当然HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

TCP连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。

关于多路复用，可以参看学习NIO 。

5 数据压缩

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

6 服务器推送

意思是说，当我们对支持HTTP2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。

服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以了，不用走网络，速度自然是快很多的。

8 详解TCP的3次握手和4次挥手

https://blog.csdn.net/qzcsu/article/details/72861891
图 tcp

1 为什么有3次握手

保证建立一个可靠的连接

2 什么是3次握手

• 客户端向服务器发请求
• 服务器接收请求
• 服务器接收请求之后发送一个连接标志

• 客户端接收连接标志之后也向服务器发送一个连接标志，至此连接完成

• TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；

• TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这时报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
• TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
• TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果
  用打电话类比的话就是：
• 小明拨打小红的电话
• 小红按下通话键并说了声，喂 （一次握手）
• 小明听到小红的回应，也说了声，喂 （二次握手）
• 小红接收到小明的回应 （三次握手）

3 为什么有4次挥手

4次挥手的作用就是断开连接，之所以要断开连接是因为TCP/IP协议是要占用端口的，而计算机的端口是有限的，所以一次传输完成之后是要断开连接的，断开连接的方式就是4次挥手。

4 什么是4次挥手

连接是由客户端发起的，所以断开连接也要有客户端发起，因为服务器是被动的。
-不携带数据则不消耗序号。
- 当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了

• 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
• 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
• 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
• 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
• 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
• 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

上图的最后一部分就是4次挥手，还是用小明和小红打电话来类比，
小明：我这没事儿了，你还有事儿吗？ （1次挥手）
小红：我也没事儿了，你确定没事儿了吗？ （2次挥手）
小红：我要挂电话了。 （3次挥手）
小明：好吧，你挂吧。 （4次挥手）