SCTP Protocol 3

tcp에서는 사진1,2,3을 따로 구분하지 않고 그냥 바이트 스트림을 보낸다.

사진1이 lost된 경우 그 뒤의 패킷들이 클라이언트로 도착한다 하더라도 앞에 있는것이 도착하지 않았으므로 커널의 네트워크 버퍼에 큐잉한다.

처음에 TCP는 고백앤 방식을 사용해서 못 받은 패킷 뒤의 수신된 패킷들을 모두 버렸지만, 나중에 셀렉티브 애크놀로지 방식으로 바뀌어서

나중에 빠진 패킷만 따로 재전송 한다. 

사진2의 첫번째 패킷,3의 첫번째,1의 두번째 패킷을 받았을때 클라이언트가 첫번째 사진에 대한 첫번째 패킷에 대한 애크를 날리지 않을것이므로 서버가 다시 재전송 한다. 클라이언트가 이 패킷을 받았을때 유저 프로세스로 버퍼에서 옮겨준다.

따라서 lost패킷의 재전송이 일어날때까지 나머지 패킷들은 커널 버퍼에만 있고 유저 프로세스 입장에서는 블락된 상태로 계속 기다릴 뿐이다.

이것은 TCP의 단점이다.

HTTP서버를 포함해서 굉장히 바쁜 서버의 경우엔 버퍼의 크기보다 수백 수천배에 달하는 양의 데이터가 수신될경우 성능이 굉장히 떨어질수있다.

이것이 Head of line blocking 현상이다. 앞대가리가 처리 안되기 때문에 뒤에 놈들이 갈수 있음에도 불구하고 기다려야 하는 상황이다.

위에서 말한 TCP의 단점을 SCTP에서는 멀티 스트림 방식으로 해결한다.

각 스트림 별로 따로 버퍼를 만든다. 사진1은 스트림1, 사진2는 스트림2...

이렇게 된 경우 사진1의 첫번째 패킷이 유실되었다 하더라도, 사진1에대한것만 블락 되고 사진2,사진3에 관한 것은 정상적으로 시퀀스 번호가 맞게 수신되었으므로 바로 커널에서 유저 프로세스로 데이터를 올려준다. 

하지만 이 상황에서도 사진1에대한 첫번째 패킷을 수신 받지 못했는데 사진1의 2번째 시퀀스 번호를 사용하는 패킷을 받았으므로 네트워크 버퍼에 큐잉 되는것은 어쩔수 없다.

아래는 위의 에코 클라이언트 프로그램을 실행 시킨 결과이다.

이 프로그램 에서는 앞에서 사용했던 프로그램과는 달리 클라이언트가 0번 스트림을 통해서 서버에 데이터를 전송했으면 1번 스트림으로 서버가 되돌려 주는게 아니라, 그대로 같은 스트림을 통해서 응답을 주게끔 만들어 놓았다.

위의 그림은 우리가 인위적으로 라우터의 설정에 10%의 패킷 손실을 발생하게끔 설정 해놓고 실험한 결과이다.

예상한대로, 1,4,6,7번 패킷들이 loss되어서 재전송 했기 때문에 클라이언트가 보낸 순서대로 도착하진 않았지만 결국엔 모든 0~9번 스트림까지의 패킷들이 도착한것을 확인할수 있다.

위의 프로그램은 바로 앞전 포스팅에서 사용했던 프로그램을 약간 바꾼 에코 클라이언트 프로그램이다.

각 스트림 0 ~ 9번에 대해서 Hello라는 메세지를 두번씩 보낸다. 그렇게 된 경우 총 20개의 패킷을 보내게 될것이다.

중요

이 프로그램을 통해서 똑같은 일을 수행해 보자.

20개가 전부다 돌아오긴 했다. 세번째 줄까지는 프로그램 설계대로 잘 동작했지만 네번째 줄부터 어긋나기 시작한다.

우리가 이 결과로부터 추측할수 있는 정보는 1번스트림의 seq1 2번스트림의 seq0,seq1, 3번 스트림의 seq0,seq1이 모두 유실 되었다.

유실의 의미는 클라이언트에서 서버로 또는 서버에서 클라이언트로 오는 와중에 유실되었다는 의미이다.

한줄 요약을 해보면 클라이언트에서 원하는 순서대로 패킷을 보냈다 하더라도 다시 서버로 부터 도착할때는 순서가 바뀌어서 수신될수있다.

스트림 번호는 패킷 유실후 재전송에 의해서 뒤죽박죽 수신될수 있으나 같은 스트림 번호라면 반드시 시퀀스 넘버의 순서가 맞아야 한다.