이석복 네트워크 (7)flow control, 3-way handshake, closing TCP connection, congetion control개요

===

http://ocw.hanyang.ac.kr/?course=8471 

컴퓨터네트워크_7회차

 

===

TCP에서 가장 중요한 세가지

reliable data transfer

flow control  --중요하지만 동작 자체는 너무나 단순해서 설명할게 없어서 sub chapter에 있다

congetion control

 

===

프로세스 간에 데이터를 주고 받을 때 각자 자기가 보내는 데이터의 속도를 조절할 수 있다. 받는 사람의 능력에 맞춘다

flow control 물을 보내는데 그 물의 양을 상대방에 맞춰서 컨트롤

 

===

TCP 연결이 생성되면 각각 내부에 버퍼 2개가 생기는데,

send buf와 상대방 recv buf가 대응

recv buf : 순서에 맞지 않는 데이터들을 쭉 쌓아놓는것, app layer에서 read()를 하면 소켓을 통해서 이게 쑥 빨려올라가는 것이다

sender의 윈도우만큼 보낼 수 있는데

recv buf의 실질적인 빈공간이 윈도우보다 적으면 보내도 의미없다 다 떨어져나가. 실제로 sender가 보낼 땐 빈공간만큼만 보내줘야 의미가 있다

 

그럼 이걸 센더한테 알려줘야해, 나 빈공간이 얼마만큼인지

이게 TCP segment에 header(HDR)부분에 receive buffer size라는 필드가 있다 거기에 담긴다  ▽이게 Window size인가

항상 내가 빈공간이 얼만큼 있는지 알려주기 위한 필드

 

receiver-drive : flow control은 항상 리시버가 drive한다

 

sender도 메시지를 receiver한테 받으니까 보낼 때 sender의 recv buf의 빈공간을 알려주고

 

이게 다야, 리시버가 도와줘서 가능

 

===

Q. flow control이 보내는 양을 조절하나요? 속도를 조절하나요?

보내는 양 : 한꺼번에 이만큼 보내는 것

속도 : 10M bps, bit per seconds. 1초 동안 얼마 데이터를 보낼거냐

∴ 양을 적게 보내면 속도가 조절된다. 같은 개념

 

recv에 맞춰서 많이 보내면 속도가 빠른 것

 

===

flow control 마이너한 이슈

app layer가 읽는 속도랑도 연관 있어, 바쁘든지해서 얘가 안읽고 있으면 버퍼에 쌓여

 

10바이트만큼 공간있다고 하면

센더는 10바이트 줘야해

 

하도 안읽으면 0바이트 리포트될것(얘를 B라고 치고)

그런 센더는 멈춰야해(얘를 A라고 하면)

그 다음엔 어떡해? 극단적으로 B가 보낼 데이터가 없는 애라고 치고, A은 멈췄고 B는 A가 보낼때까지 기다리는건데?

B한테 빈공간이 생겨도 A가 알 방법이 없어

 

TCP는 어떻게 해결하냐면 0byte가 오면 주기적으로 segment를 보낸다 DATA부분 뭐한 1byte씩 집어넣어서 이런 의미없는 segment라도 찔러줘야 ACK가 온다. ACK에 현재 상황(recv buff size)이 담기니까

▽왜 주기적으로 보내야하지 저거 하나 보내면 다시 오는데, 0오고 또 보내는게 주기적인건가

 

===

 

===

TCP를 사용해서, reliable data tranfer든 뭐든 하려면

결국에는 필요한게

- 양쪽에 버퍼 2개 만들고

- 내가 보낼 데이터의 seq number 결정해서 상대방한테 알려줘야하고

- 상대방의 seq number 트래킹, 상대방으로부터 받아와야해

 

이렇게 세팅이 되면 통신할 수 있어

이걸 하기 위한게 connection management

커넥션을 만드는 동작과정

▽TCP를 하려면 필요한 게 있는데 걔네 만드는 과정!

▽그래서 TCP connection 연결 먼저해야 되는게 직관으로 와닿고 안 까먹겠구나 저거 만드는게 없으면 아무것도 안되니까

 

===

당연히 클라이언트가 처음에 TCP connection을 열자고 요청

데이터가 왔다갔다하는건 아냐 저 위에 기반작업 3개(버퍼, seq, seq트래킹)를 하기 위한 작업을 먼저 해야해. 리소스를 생성해야해

 

이걸 TCP Three way handshake라고 한다, 3번 왔다갔다 하기 때문

1.클->서 : TCP connection 열고싶어요

=> SYN segment다, DATA부분 아무것도 없고 TCP segment 헤더부분에 SYN이라는 1bit짜리 필드가 있다. 이때만 1이다. 다른때는 다 0이야. 1일 때 SYN 패킷이라는 것

▽어떤 정보 표시할 때 필드 따로 만들어서 1 아니면 0 로 판단하게 하기 이런게 정석적인 거구나. 프로그래밍 할때 필드 하나 만들어서 기능 추가 하는게 자연스러운거네

 

이때 나의 첫 seq number를 상대방에게 알려줘야한다

 

전에 설명안한 1bit짜리 자잘한 필드들 중에

S 저게 SYN이다. 이거 1인것 보고 서버가 아 상대방이 TCP connection 열고자하는거구나 한다

 

2.서버가 그래 connection열자하는 의미로 피드백 주는게 SYN ACK

역시 SYN 플래그가 1로 적혀있고, 또 자기자신(서버)의 seq 알려줘야해 y값

SYN에 대한 ACK니까 SYN ACK의 의미로 클라이언트의 번호에 1을 더해서 보낸다(▽ACK말하는거지?)

 

3.이게 끝이 아니고 클라이언트는 SYN ACK에 대해서 또 한번 ACK를 한다. 이떈 SYN 필드가 1이 아니야. 그리고 이 세번째것은 데이터를 포함할 수 있다.

3.까지 마쳐야 리소스를 생성한다

 

1.2.만 갖고 되지 않아? 왜 굳이 3번해?

1.2.만 하면

클라입장 : 야호~ 하고 확인 받았어

서버입장 : 야호~ 했는데 내것이 갔는지 안갔는지 몰라

뭘 하면 항상 ACK를 받아야 확인이 돼.

1.2.까지 마치고 리소스를 생성하면 그 이후로 응답이 없으면 어떡해. 보안 입장에서도 공격하기 쉬워진대 잘 모르겠지만

 

===

TCP에서만 3way하는게 아니고 등산할 때 통신하면 3번 왔다갔다하는게 정석이다

뭘 하면 항상 확답을 받아야해 잘 갔는지

 

===

이 때 저 HTTP req가 3way의 세번짼데 데이터가 포함된 것

 

===

다 하고 나면 TCP connection을 끊어야 한다. 리소스들을 release

별 거 없이 FIN이라는 플래그가 1인 것

서버도 자기가 보내고자 하는 데이터가 있을 것. 클라이언트가 FIN을 보내도 내가 보낼게 남아있으면 계속 보내는 것

보내다가 다 보냈으면 나도 FIN

 

timed wait : FIN FIN 이지만 그래도 아직 저 시간 동안은 release시키지 말고 기다려. 왜? 역시 뭔가 대비해야될 케이스가 있다

맨 마지막 ACK가 유실되면 어떤 일이 발생할까? FIN 보냈는데 ACK가 안왔으니 timeout이고 서버가 다시 보낸다. 근데 클라이언트가 이미 철수해? 그럼 FIN timeout FIN timeout 계속 반복.

그래서 마지막 ACK가 정말 확실히 갈 때까지 대기하는 것  ▽재전송이 안오는거 확실하게 본 후 겠지

 

===

지금까지 한 것 총 정리 그림. 별 다른 내용 없다

 

===

congetion control 개요

 

flow control : 데이터를 보내는 속도를 자기가 조절할 수 있지만 실제론 리시버의 상황에 지배를 받는다

여기에 더해서 사실 중간에 Network라는 인프라의 영향을 받아

 = 받는 사람의 능력, 중간 전달자들의 능력 둘다 고려해야해, 둘 중에 상태가 더 안좋은애한테 맞춰야 한다, 계속 체크해야해

 

네트워크 상태 어떻게 알아? 집합체인데? congetion control이라는 걸로 알 수 있다

 

===

결국엔 A와 B사이에 데이터 전송인데 그 중간에 Internet이란 Network가 있다

보내는 사람은 누군가의 통제가 없으면 그냥 막 보내는게 편하지 인간의 욕망이다. 빨리 보내고 싶으니까

그럼 막혀 고속도로가 막히듯

TCP는 네트워크가 막히면 더 네트워크를 악화시키게 행동한다. 안가면 재전송하니까. 원래 보낼 데이터가 10MB면 재전송하게되면 20MB. 실제로 보내게 되는 데이터의 양은 더 많아진다. TCP는 네트워크가 막히면 망해

 

TCP가 제대로 동작하려면 네트워크가 막히지 않게 해야해

네트워크가 막힐 것 같으면 각자가 보내는 데이터를 줄여야해 각자 자신을 위해서. 크게 보면 서로를 위한 길이 된다

 

UDP는 무법자야. 대신 reliable하지 않으니 유실됨

 

===

flow control은 그냥 줘서 알았는데

네트워크는 뭘로 알아?

네트워크가 정보를 주든지,

라우터들이 자신의 큐에 들어있는 상황을 나한테 알려주는 것 : 이건 구현이 안돼있다. 라우터들이 그럴 시간이 없대

 

->실제 현재 인터넷에서 구현되는 방식은 End-end congetion control : 라우터는 바쁘니까 엔드끼리 네트워크 상황을 유추해서 알아서 해봐라

->TCP segment왔다갔다 하는걸로 유추하는것임, ACK가 느리게 오든지 안 오는걸로, 그러므로 아주 정확하진 않다

 

===

전송하는 속도, 전송 양을 조절하는건 send buf야 이 안에서 윈도우가 움직여

피드백이 잘 안오면 윈도우 사이즈가 줄어들고, 반대는 반대고