- flow control : 호스트간의 data 처리를 효율적으로 하기위한 기법, 송신측과 수신측의 데이터처리 속도 차이 해결
- congestion control : 호스트와 네트워크 상의 데이터처리를 효율적으로 하기위한 기법으로 송신측의 데이터 전달과 네트워크의 처리속도 차이를 해결하기 위한 기법
- data가 올때마다 ACK을 보내는 것은 비효율적이다. ACK보낼때 20bit짜리 헤더가 계속 붙기 때문이다. 보낼 때 여러데이터를 보내는 것이 효율적이므로 윈도우 사이즈 개념을 이용한다.
send window와 receive window
-
send window : receive측에서 보내준 ACK과 함게 Header에 담겨있는 rwnd 정보를 계속 확인한다.
-
receive window : allocate buffer는 총 할당된 크기이고 Receive Window Size가 sender에게 얼만큼의 byte를 받을 수 있는지 표시하는 용도로 쓰인다.
흐름제어 (Flow Control)
- 오류제어(error control)에서 흐름제어를 따로 공부한다.
- rwnd를 알기위하여 SYN을 보낸다.
- receiver는 ACK과 함께 rwnd를 보낸다. 이를 받은 server는 그만큼의 rwnd를 send window의 설정한다.
- sender가 데이터를 write()하다가 전송하면 receiver는 그것을 받고 ACK을 보내 다시 rwnd를 전송한다.
ACK을 받은 server는 남긴 전송한 data를 삭제하고 rwnd를 확인하고 그만큼의 공간을 확보한다. (sliding window방식 : closing & opening)
- receiver도 소모한 만큼 rwnd 값이 바뀜.
- sending buffer를 keep하는 이유: 데이터가 유실될 경우를 대비하여 재전송하기 위하여 유지한다.
Silly Window Syndrome
송신측에서 발생하는 신드롬
- 너무 천천히 sending buffer를 채워서 생기는 문제
- Nagle 알고리즘
- 보낼 데이터가 MMS(Maximum Segment Size)만큼 쌓이면 무조건 전송한다.
- 상대로부터 ACK이 오면 MMS보다 작아도 전송한다.
수신측에서 발생하는 신드롬
- application측에서 buffer를 너무 느리게 가져다써서 생기는 문제
- Clark 해결방법:
- MSS(Maximum Segment Size)까지 비우거나 buffer를 반정도 비우면 ACK을 보낸다. 그 전까지 server에게 rwnd는 0으로 전송한다.
- 확인응답의 지연
- ACK 전송을 지연시켜 서버에서의 data 전송을 중단하게끔 한다.
SYN Flooding
- Client가 서버가 열어놓은 할당양만큼 연결요청하여 SYN을 보내면 서버측에서 SYN + ACK을 보내는데 이때 client가 ACK을 보내주지않아 메모리공간이 꽉차 연결이 불가능해서 서버가 서비스를 중단해야되는 상황이다.
Error Control
- checksum, acknowledgment, time-out을 이용하여 해결
Acknowledgment
- 보내는 data의 순서를 보장한다.
Rule1
- 데이터가 오면 바로 ACK을 보내는 것이 아니고 buffer에 데이터가 있는지 확인하여 ACK 보내는 김에 데이터도 같이 보내 손실을 줄인다.
Rule2
- 만약 데이터가 하나만 오고 지정해둔 timeout값을 넘긴다면 그때 ACK을 전송한다.
Rule3
- ACK을 줄이기위한 방법으로 Cummulative ack의 특성을 이용하여 data가 두개 도착하였을 때 하나의 ACK을 보낸다.
Rule4
- packet의 loss를 감지하면 바로 받아야할 packet의 번호를 ACK에 적어 전송한다.
Rule5
- loss됐던 packet이 재전송되면 바로 ACK을 보낸다.
Fast Retransmission
- packet의 loss가 일어났을 때 정상적인 ACK이후에 중복된 ACK이 세번 반복적으로 보내지면 다시 유실된 packet을 보내는 작업이다.
Lost Acknowledgement
Rule6
- ACK을 보낸 데이터의 데이터가 다시 오면 ACK이 유실됐음을 감지하고 다시 ACK을 전송한다.
ACK의 유실은 DEADLOCK으로 이어질 가능성이 있다.
- receiver에서 rwnd=0이라 보냈다가 Clark 방법으로 rwnd의 size를 재정의해서 전송하는데 이때 이 ACK이 유실되면 서로 대기하는 상황이 발생한다.
해결책
- Persistence Timer
- rwnd값이 0일 때 켜지는 타이머이다.
- 교착상태를 방지하기 위하여 영속타이머가 만료되면 서버의 사태 확인용으로 probe 세그먼트라는 작은 byte의 packet을 전송하여 rwnd값을 확인한다.
