[네트워크] 응용계층과 전송계층

Q) 패킷 단위 데이터를 전송할 때 발생하는 딜레이 종류와 그에 대한 해결법을 설명해보세요.
A) processing delay는 패킷에 문제가 있는지, 목적지가 어딘지 등을 확인하는데 소요되는 시간입니다. 라우터의 성능 개선을 통해 이 딜레이를 줄일 수 있습니다.
queueing delay는 유저가 많을 때 데이터가 바로 라우터를 통해 빠져나가지 못하고 잠시 임시 버퍼에 저장하는데 이 큐에서 대기하는 시간을 뜻합니다. 사용자가 과하게 몰리지 않도록 하면 딜레이를 줄일 수 있습니다.
transmission delay는 패킷의 맨 앞 비트부터 마지막 비트까지 뿜어져 나가는데 걸리는 시간입니다. 이때 전송 통로가 크면 클수록 소요 시간이 짧아지기 때문에 케이블을 넓히는 방법으로 딜레이를 줄일 수 있습니다.
propagation delay는 패킷이 케이블을 통해 다음 라우터까지 가는데 걸리는 시간입니다. 빛의 속도로 일정하기 때문에 이 부분에 대한 개선은 매우 어렵습니다.


Q) HTTP 프로토콜은 무엇인가요?
A) HTTP 프로토콜은 하이퍼텍스트를 주고받는 프로토콜로, client가 request메세지를 보내면 server가 response 메세지를 보냅니다. HTTP 프로토콜은 전송계층에서 TCP 프로토콜을 사용하기 때문에 먼저 TCP connection을 사용해야 합니다. 이때 효율적인 통신을 위해 커넥션을 지속하는 방법을 사용하기도 합니다.


Q) Multiplexing과 Demultiplexing은 무엇인가요?
A) 전송 계층이 제공하는 기능으로, 멀티플렉싱은 응용계층의 수많은 프로세스들이 보내는 메세지를 전송계층에서 하나의 세그먼트로 묶어서 아래 계층으로 전달하는 기능입니다. 디멀티플렉싱은 반대로 리시버 측에서 전송계층에서 받은 세그먼트를 응용계층의 많은 프로세스 중 정확한 소켓에 전달하는 기능이다. 이게 가능한 이유는 디멀티플렉싱은 세그먼트 헤더에 그에 대한 정보가 적혀있기 때문입니다. 헤더 필드 중 source port, dest port가 있어서 정확히 목적지 소켓으로 전송이 가능합니다.
+) UDP의 경우 dest IP와 dest Port로 어떤 소켓으로 올릴지 demultiplexing이 이루어지고
TCP의 경우에는 source IP, source port, dest IP, dest port이 4가지 튜플이 있어야 demultiplexing이 이루어진다.


Q) TCP와 UDP는 무엇이 다른가요?
A) TCP(Transmission control protocol)은 신뢰성을 보장하는 연결형 프로토콜입니다. 내가 전송한 순서대로 도착지까지 전송되며, flow control을 통해 센더와 리시버 사이의 속도를 맞춰주고 congestion control을 통해 센더와 리시버 사이의 네트워크 상태에 따라서 데이터 전송을 조절합니다.
UDP(User Diagram protocol)은 신뢰성을 보장하지 않는 프로토콜입니다. 커넥션을 맺지 않으며 flow control과 congestion control을 하지 않습니다.


Q) Reliable data transfer는 무엇인가요?
A) RDT 프로토콜은 신뢰성있는 데이터 전송을 위한 프로토콜로, 전송 계층 이하에서 패킷의 에러와 유실을 방지합니다. checksum으로 에러체크를 하고 리시버는 ACK로 패킷에 대한 피드백을 줍니다. 에러 발생 경우 패킷을 재전송하고 이때 새로운 패킷인지 재전송된 패킷인지를 구별하기 위해 시퀀스 넘버를 사용합니다. 또 패킷 유실은 타이머를 통해 판단할 수 있습니다.


Q) GBN 방식과 Selective Repeat 방식을 간단히 설명해주세요.
A) 파이프라인 방식으로 한번에 여러개의 패킷을 전송할 수 있는 방식입니다.
GBN은 window size만큼은 피드백을 받지 않고 보냅니다. GBN방식에서 ACK는 해당 번호만큼 잘 받았다는 의미입니다. ACK를 받으면 해당 패킷을 윈도우에서 제거하고 다음 패킷을 윈도우에 추가합니다. 리시버는 원하는 패킷이 아닐 경우 그냥 버리기 때문에 하나의 패킷이라도 오류나 유실 발생시 센더는 윈도우 크기만큼 패킷을 재전송합니다. 윈도우 사이즈가 수천 개에 달할 경우 낭비가 심해진다는 단점이 있습니다.
Selective Repeat은 GBN의 단점을 보완하기 위해 리시버는 패킷을 임시로 저장할 수 있는 버퍼를 가지게 됩니다. 순서에 맞게 들어오지 않으면 일단 버퍼에 패킷을 저장합니다. 센더는 ack를 받지 못한 패킷을 재전송합니다. 그러다 버퍼에 모든 패킷이 차게 되면 모든 패킷을 응용 계층에 올리고 ACK를 보냅니다.


Q) TCP 프로토콜의 특징을 자세히 설명해주세요.
A) TCP는 1대1 연결이고 신뢰성을 보장하는 프로토콜입니다. 한꺼번에 여러개의 패킷을 전송할 수 있고 양방향 통신이 가능합니다. TCP의 가장 중요한 기능은 reliable data transfer, flow control, congestion control입니다.


Q) TCP의 3-way handshake와 4-way handshake를 설명해주세요.
A) 센더와 리시버가 통신을 하기 전에 3-way handshake로 연결을 성립합니다. 첫번째로 클라이언트는 서버에게 SYN 패킷을 보냅니다. 그리고 자신의 시퀀스 넘버 x를 보냅니다. 서버는 똑같이 SYN과 시퀀스 넘버 y를 보내고 패킷을 잘 받았다는 의미의 ACK=x+1을 보냅니다. 클라이언트는 응답을 받고 마지막으로 ACK=y+1을 보냅니다. 이 과정에서 클라이언트, 서버는 ACK를 받고 센더용 버퍼, 리시버용 버퍼를 생성하게 됩니다.
통신 해제 시는 4-way handshake가 사용됩니다. 먼저 클라이언트는 연결 종료를 의미하는 FIN 플래그를 보냅니다. 서버는 FIN을 받고 확인의 의미로 ACK를 보냅니다. 이후 데이터를 모두 보냈다면 연결이 종료되었다는 의미의 FIN을 클라이언트에게 보냅니다. 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보냅니다. 서버는 이 ACK를 받으면 close를 하고 ACK를 받지못하면 다시 FIN을 보냅니다. 이때 서버가 마지막 ACK를 받지 못할 경우를 대비하여 클라이언트는 마지막 ACK를 보낸 후 일정시간 기다렸다가 close합니다.


Q) TCP의 RDT(Reliable data transfer)을 설명해주세요.
A) TCP의 ACK는 해당 패킷 전까지 잘 받았으니 이 패킷부터 보내라는 의미입니다. TCP는 하나의 타이머만 가지고 있어서 GBN과 달리 전체 윈도우를 다시 보내지 않고 터진 세그먼트만을 다시 보냅니다.
센더는 타임 아웃이 되면 재전송합니다. 그리고 리시버가 보낸 ACK가 유실되어 중복된 패킷을 재전송해도 리시버는 제일 최신 ACK를 전송합니다. 그리고 센더는 받은 최신 ACK로 판단하여 전송합니다.
센더가 항상 타임아웃될 때까지 기다렸다가 재전송하는 것은 비효율적이기 때문에 센더는 중복된 ACK를 3개 더 받게 되면 해당 패킷이 유실되었다고 판단하고 해당 패킷을 재전송합니다. 이를 fast retransmit이라고 합니다.


Q) TCP의 flow control에 대해 설명해주세요.
A) TCP는 파이프라인 방식으로 여러 개의 패킷을 보낼 수 있는데 리시버가 받을 수 있을 만큼의 속도로 보내주는 것이 flow control입니다. 리시버가 센더에게 보내는 세그먼트 헤더 중 receice window라는 칸에 남은 버퍼의 사이즈를 담아서 전달합니다. 센더는 이 세그먼트를 받고 남은 버퍼 사이즈만큼만 데이터를 보냅니다. 버퍼는 단순히 유실 데이터가 있어서 그 다음 데이터를 담는 용도로만 사용되지 않고 리시브 버퍼에서 응용 계층으로 올리는 속도와도 연관이 있습니다.
+) 리시버는 버퍼가 가득차면 receice window에 0바이트 남았다고 보내는데 이 이유로 센더가 아무것도 보내지 않게 되면 리시브 버퍼에 공간이 생겨도 센더는 이를 알 방법이 없기때문에 센더는 리시브 버퍼가 0이어도 계속 1바이트씩 데이터를 보냅니다.


Q) TCP의 congestion control에 대해 설명해주세요.
A) 데이터를 보낼 때는 네트워크가 감당할 수 있는 양만큼의 데이터를 보내야 합니다. 이를 조절하는 것이 congestion control입니다. 네트워크 상황을 직접 알 수는 없기때문에 네트워크 상황을 유추하는 방법을 사용합니다. congestion control은 3가지 페이즈로 구성됩니다. 첫번째 페이즈는 slow start입니다. 처음엔 네트워크 상황을 모르기 때문에 아주 조금씩 보내면서 대신 증가폭을 2배씩 크게 늘려갑니다. 두번째 페이즈는 Additive increase입니다. 늘려가다 threshold에 도달하면 증가폭을 조금씩만 늘리는 것입니다. 너무 커지면 과부하가 발생할 수 있기 때문입다. 세번째 페이즈는 Multicative decrease로 그러다 유실이 발생하면 데이터 전송량을 반으로 확 줄이는 것입니다. 이후 다시 첫번째 페이즈부터 반복합니다. 예전 버전인 Tahoe버전에선 3번째 페이즈가 되면 threshold를 유실이 발생한 지점의 윈도우 사이즈의 절반으로 재설정합니다. 최신 버전인 Reno 버전에서는 데이터 유실 대처 방안을 두 가지로 나눕니다. 일단 타임 아웃으로 인한 데이터 유실의 경우 네트워크 과부하가 걸린 것으로 판단하고 Tahoe와 같은 방식으로 처음부터 시작하게 됩니다. 3개의 중복된 ACK를 받게 되는 경우 하나의 패킷만 전송이 안되는 경우로 판단하고 Threshold가 낮춰진 그 지점부터 시작하게 됩니다.