- IPv6-Only 네트워크로의 전환
- 역사
- IPv4만 가지고 통신
- NAT추가
- IPv4와 IPv6의 공존
- IPv6만 지원하는 네트워크의 증가
- 현재 50% 이상의 셀룰러 사용자가 IPv6를 사용
- IPv4만 지원하는 서버와 IPv6만 지원하는 단말기를 위해 DNS64와 NAT64를 둠
- 따라서 15년 이후부터는 IPv6를 앱이 반드시 지원해야한다.
- 다행히 70% 정도의 앱은 별다른 영향을 받지 않는다.
- 하지만 나머지 30%는 IPv4만 지원한다.
- 이는 IPv4만 지원하는 API를 사용해서이다.
- preflight 테스트를 할 때 IPv4를 사용하면, 인터넷에 연결 되어 있어도 실패하는 경우가 있을 수 있다.
- 추천하는 방법
- 네트워크 체크하지 말라
- 상위 레이어의 네트워크 프레임워크를 써라
- 이름 기반의 API를 쓰라 -> IPv4주소를 쓰면 DNS64에 쿼리가 가지 않는다.
- URLSession과 CFNetwork를 쓰면, IPv4를 써도, OS 레벨에서 IPv6와 통합을 해준다.
- 어떻게 앱을 빠르게 할 것인가?
- 딜레이 줄이기
- Reliable Network Fallback -> 커넥션 설정 시간 감소
- Wi-Fi Connection이 잘 안될 경우, 셀룰러 데이터로 자동으로 바꿔서 연결을 하는 것 -> 와이파이 키는 것을 잊어서 셀룰러 데이터 폭탄을 맞는 것을 방지해준다.
- 이를 위해서는 당연히 앱에서 셀룰러 연결을 허용해야 한다.
- Explicit Congestion Notification
- 데이터를 보내는 속도와 받는 속도가 차이가 나면 버퍼링이 일어나고, 버퍼가 넘치면 데이터 손실이 일어난다.
- 해결책: 좀 더 스마트한 Queueing
- CoDel: Controlled Delay queuing
- 버퍼에 무작정 데이터를 넣는 것이 아니라 혼잡상태를 보고 조절해서 넣는다.
- bufferbloat를 막는다.
- (ECN)Explicit Congestions Notification
- 패킷을 버리지 않고 마킹해서 다시 보냄으로 혼잡도 시그널을 보내는 것
- 위 두가지를 합치면 좋은 결과를 얻을 수 있다.
- 애플리케이션의 흐름이 변화하면서 ECN의 필요성이 증가했다.
- 파일 전송, 이메일 등은 정해진 데이터 량을 보내는 것이기 때문에 시간이 오래걸려도 상관없었다. 순서도 알아서 맞추면 됐었고.
- 하지만 지금의 스트리밍 시대에서는 시간은 정해져있기 때문에 데이터 전송을 유동적으로 조정해서 끊김없는 경험을 제공해줘야한다. 또한 순서가 뒤바뀌어서 들어오는 것에 취약하기 때문에 더 그렇다.(손실에 민감)
- 클라이언트가 이를 지원하는 경우가 많지 않았는데, 이제 애플 디바이스는 이를 자동으로 활성화시킨다.
- 지원하는 라우터가 적어서 오류가 생길수 있겠지만, ECN을 지원하는 디바이스가 많으면 점점 이를 지원하게 될 것이다.
- TCP_NOTSENT_LOWAT(Low water): Sender측 딜레이를 줄이는 것
- DSL같은 경우는 비대칭이여서 업로드가 다운로드 보다 많이 느리다.
- 그래서 저 옵션을 주면, 소켓 송신 버퍼(socket send buffer)는 그대로지만, 버퍼의 대기량이 낮아질 때만 송신 버퍼를 채우도록한다.
- 즉, 버퍼에서 오랫동안 대기하고 있던 데이터를 처리하는데 시간을 덜쓰겠다는것이다.
- 좀 더 조금씩 자주 채우겠다는 것.
- TCP Fast Open
- TCP 연결을 위한 Handshake에 데이터를 섞어 보내서, 단계수를 줄이는 것