TCP 특강

분산 시스템의 8가지 오류: 전송 비용 크다, 한 지저부터 다른 지점으로 도달할 때 중간 경로가 항상 달라진다. 뭔 트레이스 관련 명령어 사용하면 중간 경로 확인할 수 있다.

 

tcp 의 가장 어려운 문제: 유실과 딜레이. 또는 croption이라고 해서 데이터가 변형되는 경우도 있다. 광랜을 사용하면 괜찮지만 전기적으로 믿을 수없는 인프라 하에서라면 가능성이 있는 경우도 있다. 이런 단점들을 커버하는 것이 , 이 신뢰없는 네트워크에 신뢰를 부여하는 tcp 다,

 

라우터는 네트워크에 따라 다른 경로로 보내줘야 하고, 이를 위해 transmission 해야 하는데, 이 때 큐잉을 한다. 하지만 시스템이라 메모리 라우터 버퍼에 한계가 있기 때문에 새로운게 들어와도 메모리 부족하면 패킷을 버리게 된다. 따라서 트래픽이 많으면 유실이 자연스럽게 발생하게 되는 것이다. => 큐잉 딜레이라고 한다

 

라우터도 데이터에 대한 검증을 해야함. 패킷 지연의 4가지 요소라는 슬라이드 보면 이게 딜레이 되는.. 4가지 요인 이건 유용하다. 몰랐거든

매질 즉 구리냐 광랜이냐. 하는 것에서 전파 속도가 다름 이게 propagation 의미임

transmission = 라우터에서 광랜 같은 매질로 넘겨주는 것. 매질을 지나가는게 프로파게이션

혼잡제어, 유량 제어할 떄 이 4가지를 따지는 경우가 있기 떄문에 이야기를 한 것!

더 좋은 라우터일수록 더 졸은 transmission rate를 갖고 있다. 

 

 패킷 큐는 선형적으로 증가하는 게 아니라 기하급수적으로 증가한다. 임계점 넘으면 왁 수직상승 해버리는 원리인거지, 그게 아니라면 그냥 완만한 증가...

 

4계층과 3계층 간 가장 큰 차이는 뭘까? 4계층은 프로세스에게 전달해준 다는 점, 네트워크 디바이스 즉 3계층은 컴퓨터에게 전달해주는게 목적이라는 점.

호스트명은 컴퓨터 주소를 말하는 건데, 

DNS도 5계층 작동.

3계층= ip

4계층에서 오가는 데이터 = 세그먼트라고 한다. 

3계층서 오가는 것 = 데이터그램

2계층 = 프레임

메시지-세그먼트-데이터그램-프레임. 순서다.

데이터그램 안에 세그먼트 1개만 쓴다. 세그먼트 안엔 tcp  헤더가 있는데, 이건 아이피 헤더랑 쌍으로 들어간다 항상.

tcp segment 사이즈는 제약이 없다. 보통은 네트워크에서 정의돼있다. 왜 앞뒤 모순인...

스위치는 2계층까지, 라우터는 3계층까지만 있다. 라우터는 호스트로 보내는 것이기 때문에 3계층까지 까보고 다시 옷 입혀서 다음 목적지인 최종 호스트 즉 일반적인 개인컴 같은 것으로 보낸다.

만약 vpn 등을 타고 가면 이 경로 더 길어진다. 사내에서만 하는 거면 스위치, 라우터등은 안거치거나 덜 복잡하게 거친다.

 

먹싱, 디먹싱 = 멀티플렉싱 ㅇ줄임말이네

여러 채널의 요청을 모아서 배달하는 것 = 멀티플렉싱. 다 신뢰 전송(TCP)을 위해 하는 것이다!

 

유량제어는 뭐 했을 때 문제가 될 수 있다는데 근데 이게 뭐냐... 5계층 레벨ㅇ에서도 이를 할 ㅜㅅ 있는데, 데이터 많이 보내는데 서버가 준비 안돼있으면 서버가 일을 못해 요청응답 처리가 자꾸 밀린다. 그럼 신뢰전송 자체는 되고 있는데 유량 제어를 못하는 상황인 것.

 

혼잡제어는 유량제어하고 비슷하긴 하나, 후자는 송신자와 수신자의 관계 상에서 속도 혹은 보내는 양의 문제를 막ㄱ 위한 것. 전자는 가는 길 즉 도로 상황이 문제인 것. 도로의 개수나 너비는 정해져 있기 때문에... 출근길이라 치면 출근 시간 늦추거나, 재택하거나 아예 안하거나 이런 방식 생각할 수 있잖아. 이런게 혼잡 제어

 

전송계층과 UDP도 조금 볼 것임

 

tcp는 기본적으로 호스트 와 호스트 간 프로토콜이므로, 서버 프로세스와 클라 프로세스간 논리적 연결, 전송을 책임져주는 프로토콜이라고 재정의할 수 잇따.

 

유디피는 순서도 신경 안씀. 그래서 순서 상관없이 오는 경우도 많. 도움을 주는 게 없

tcp 는 지연 시간에 대한 보장 을 안해준다는 문제가 있다 .이를 테면 5분 이상 지연 안되게 해준다 이런거 못함. 이런건 5계층에서 해주는 것임. 네트워크도 잘 짜고 하웨도 잘 구성해야 함. 하웨 밴드위스 안되면 소용없기 떄문. 따라서 지연시간에 대한 보장은 이렇게 해주는 거지 프로토콜이 해주는 게 아님. 밴드위스는 하드웨어 개런티.

 

예시. 아파티 웹 서버에서 메시지 갖고갈 때, 얘가 송수신 하고 파폭 브라우저가 메시지 받는 입장이라 쳐보자. 이럴 때 먹싱과 디먹싱 이야기 할 거임.

먹싱은 채널 있는 것하나로 관리하는 것이고 그 반대는 그 반대.

피쓰리, 피포에서 피원피투(한 컴 안에 있음)로 가는건 디먹싱, 그 반대는 그 반대.

피원 피투가 센더인데,

원하는 헤더 추가해서 접속 건수가 몇이었네? 이런 것들 볼 수 있

디먹싱 할 때 다시 한 번 강조할 것은 아이피 데이터그램을 호스트에 받아, 그럼 그 위에 전달해주기 위해 다시 패킷 꺼내야 하는데, ... 아무튼 원투원으로 매칭된다는거. 티시피 연결을 5 tuple 이라고 함. 실제로 티시피 헤더에 정의된 것은 

세그먼트에는 아이피 정의 안돼있으니,아이피 헤더를 까봐야 함. 유디피토 포트만 들고있지 아이피 데이터그램 안에 들어있기 떄문에 이걸 본인 헤더에 들고 있지 않는다는 것.

포트만 있다는 거.. 데이터그램 소켓에 로컬 포트 지정해줘야 함. 혼자선 포트 저장 안해서...

티시피도 당연히 포트 지정해줄 수 있음

 

"비연결형 디멀티플렉싱" 이런 식으로 먹스 디먹스 개념 적용이 가능한 거구나.

커넥션 연결 타임 = RTT(round trip time).이거 계산해서 지연 시간 등을 조정하는 것임.

udp는 이런거 계산 안해도 되기 때문에 그런 차원의 오버헤드는 없

치팅 - 혼잡제어를 하지 않는다. 그럼? 그래서 정말 혼잡한 상황에선 얘가 더 빠르게 되는 것

udp는 dns, 멀티미디어 전송 등 loss tolerant 일 때 많이 쓴다.snmp도 그렇.

http3는 혼잡 유량 제어등 다 해야 하는데 나몰라라 하고 udp 써버림 => 5계층에서 이걸 구현하겠단 의미임.

티시피는 운체 커널로 들어가는데 문제는 서로 커널이 많이 다름. 근데 구글이 크롬 웹브라우저에서 알아서 이런거 구현해서 udp 쓰겟다고 해버리면.. tcp는 한번 고정되고 나면 바꾸기 힘든 것에 비해 udp 는 안그렇기 때문에 결국 본인들 패권을 차지하기 위해서 이걸 표준으로 만든 것일 것이다.

 

udp 의 체크섬은 몇 가지 헤더들을 갖고 ... 뭘 더할 거냐? 헤더의 내용 갖고함. 결국 이거 만드는 알고리즘은 그냥 덧셈 연산이다.

 

단점은 변경 감지 못할 수 있음. 이런것까지 변조될 게 우려된다면 5계층에서 별도의 체크섬 관련 알고리즘을 짜야할 것이다.

 

드디어 제대로 tcp 시작. 이 교수님이 이걸 바까틍로 빼둔 이유가 http3 때문에 그런 것임. 이게 아니면 똑같은 걸 

ip multicast...

 

reliable data transfer... 

 

운체 단위에서 스레드 말고 프로세스만 바껴도, 두 놈이 상태를 공유하기 매우 힘들기 때문에 이정도만 되도..음 암튼 이걸 송신자 수신자 네트워크로 봐도 무방하다는 말을 하고 싶은 가봐.

프로토콜 버퍼... tcp buffer 같은게 따로 또 있구나..

tcp는 송신자 수신자 구분이사실상 없음. 서버 클라를 논리적으로 구분할 수는 있지만, 단방햐응로의 두 가지 채널이 열려있단 점에서는... 그러핟는 것.

 

 

이제 RDT(reliable data transfer) 프로토콜 시작 할 것. 

이제 프로토콜 ㄱ짤 건데, 통신 네트워크 프로토콜 짤 떄 각 통신 채널에 대해 상태가 있다 (상태 머신 등장할 것 같음)

이를테면 챗ㅈㅍㅌ 접속한 상태. 이에 대한 연결은 하나의 상태 로 구성되는 상태 머신을정의할 수 있음. 네트워크에서 상태 전이... 가 발생하거나, 원래 상태가 발생하거나 한다. 상태 개수가 유한하므로 final state machine이라고 한다.

 

RDT1.0부터 정의 . 채널이 reliable 하다 침. 로스도 없고 등등. 이라면 1.0ㅓ 버전.  신뢰하기 ㄷ때문에 별다른 걸 할 필요는 없지만, rdt는ㅍ로세스가 자길 불러주길 기대하고 있ㄱ 때문에 사실상 송신자.

 

2.0 은 변형이 발생한다. 이거 발생하면 udp 에서처럼 체크섬 검사한다고 했잖아? 이에 대한 체크를 항상 하는 것.

그럼 에러 발생하면? 이엗 ㅐ한 건 여러 방법이 있을 수 있음. 내가 지금까진 유실 같은게 있는거 아니고 오류만 발생할 수 있음 그럼 여기서 ACK와 NAK을 정의 . nak = negative ack.

stop and wait. 하나 보내면 하나 기다린다. 원랜 이렇게 하면 절대 안되지만여기선 그렇게 하기로 함.

결론적으로 ack 만 있어도 크롭션 에러 해결 가능. 그러나 여전히 심각한 오류를 내포하고 있다. ACK, NAK 자체가 크롭션 될 수 도 있다.

따라서 ack에 대한 ack/nak...이것 자체에 대한... 이게 crop 됐냐 하는 걸 체크해줘야 한다.

그럼 ack이 잘못올 수 있다는 가정이 달린 한, 이게 어디서 온 것인지를 알아야 할 필요가 생겼다.

rentransmission은 가능해졌기 때문이다.

 

이제 똑같은 데이터 2번 오면, 로스는 없기 때문에 무시하기로 하는 룰을 추가.따라서 수신자가 duplicate check를 하기 시작.

 

RDT 2.1: 2.0이 틀려서 만든 것. 이제 패킷에 시퀀서 넘버 추가했잖은가. 현잰 stop and wait 방식이기 때문에 0하고 1을 toggle(즉 서로  왔다갔다 함) 하는 상황이잖아?

ack이 깨졌을 떄 다시 보낸 건지 아닌 건지 어케 아나? 이걸 알려줘야 한다

 

RDT 3.0. 이제 새로운 패킷을 유실할 수 있는 상황. 그럼 재전송 해야 하는데 어케 하나? 이제 타이머 (타임아웃)를 설정해야 한다

타이머가 돌기 시작하면서부터는 데이터 중복이 많이 생길 수 있다는 문제가 생김.

 

stop and wait 일 때의 round trip time 생각해봐라. 얼마나 밴드위스가 좋을 지도 모르는데, 넘 비효율적이다.

프로토콜 잘못 설계돼갖고 하웨를 충분히 활용하지 못하는 상황이 되는 것. 이제 이 통신 프로토콜 쓰는 애들은 너무 느려지게 됨.

이 문제 해결 법은 동시에 여러개를 보내는 일 = 파이프라이닝. 마치 cpu에서 동시에 여러 연산 하는 것과 비슷.

tcp는 rtt 등을 추적하면 통계적인 애가 된다.

 

파이프라이닝 하는 실제 프로토콜? 중 하나가 Go badk n이란 프로토콜이다. 동시에 보낼 ㅅ수 있는 데이터 개수에 한계를 두는 것. 이제 윈도우 나온다.

 

ack이 온 것은 이미 받앗기 땜에 쓸데없는 정보인데, 버려지지가 않아 쓸데없는 공간 차지.

 

지금껏 나온 ack 보다 좀더 좋은 ack = cumulative ack. 퉁쳐서 여러 개 데이터에 대해 하나의 ack 만 보내는 것. tcp는 이 ack 방식을 쓴다. 혹시 카프카도 이것?

항상 ack을 보내는 데 , 받은 것에 대해 보내는 것 말고 시퀀스에 대해...

 

아까 나온 스탑 앤 웨잇 성능 이슈.. 나중 가면 유실이 기하급수적으로 증가하면(전달 안하는게 많아지는) 이제 혼잡 제어가 들어감. 이 떄 시퀀스 넘버가 들어가며, 파이프라이닝의 효율성, 데이터 전송횟수 줄이기 문제를 고려한다. 네트워크는 그리 단순하지 않기 때문에 이것들을 각각 최적화 하는 방식도다르고, 일반화하기는 까다롭다. 아무튼 현재 tcp의 원형이 되는게 아까 나온 go back N 프로토콜에 해당하는 것.

 

실제 tcp에 대해 이야기 해보면, 줄맞춰서 가긴 하지 물론. 파일 전송의 특징을 갖고 있지. 줄지어서 가는... ㅌ독특한 특징. 그래서 메시지가 없다고 볼 수 도 있음 사실상.

tcp ack의 초기값은 랜덤임(보안이슈때문에). 사이즈 계속 더해가는 방식은 똑같음.

full duplex니까, 반대쪽의 ack이 한 쪽의 seq로 간다던지... 그렇다. 텔넷 간 통신 역시 이런 식으로 동작.

타임아웃을 얼마로 둘 것인가? 당연히 rtt 보단 길어야 할 것임. 그 반대로 하면 절대로ack을 받을 수 없고 문제가 되겠지.

그러나 rtt가 분산이 크기 땜에 (값이 다양), ㅡ샘플링을 한다. 이를 추적할 떈 retransmission 된 것은 제한다. 따라서 exponential weighted moving average 함수 이용해 정의한다(EWMA)

 

safety margin은 표준편차 반영해줌으로써 실현한다. 4시그마 정도를 곱해준다.

네트워크는 패킷수를 줄이는게 중요하기 때문에, 500ms 정도 쉬고 보내주면 ㅈ좀 낫다. 단, 누락된 데이터에 대해선 빨리빨리 보내줘야 한다. => 스레드 우선순위고려해서 이에 대한 코딩 한다던지... 하는 식으로 반영할 수 있겠지?

만약 ack 이 3번 이상 온다. 그럼 메시지 유실이 확실하니 다시 보낸다! 와 같은 식의 룰 체크도 가능.

 

이제 유량제어 연결관리 혼잡제어 3개 남았따.

 

tcp가 보낼 때, 나 얼마만큼 보낼 수 있어라도 정해진 window size 를 같이 보내서 실어준다. 그럼 이를 반영해서 이 값을 이용해유량제어 되는 것.

버퍼로 따지면 현재 남은 버퍼 공간 만큼을 계산해서 윈도우 사이즈에 실어서 보내는 것. 요새는 tcp buffer 소켓 사이즈도 조정할 수 있다. 옛날엔 4k 밖에 안됐는데 요샌 10m 씩도 됨. 광랜 같은거 쓰면 워낙 통신 환경이 좋기 때문에 이정도는 필요하게 됨. 인트라넷에서 잘 된다 (=네트워크 훌륭한 곳)

만약 3way hand 아니고 2way 일 땐 무슨 문제? 데이터 유실 문제, 2번 이상 커넥션 발생 등의 문제가 생길 수 잇다. 연결도 안맺어졌는데 2번 이상 보낼 수 없기 때문.따라서 잘못하면 클라이언트를 못 볼 수 도 있고...

그래서 먼저 syn - synack - ack을 보내는 순서인 3way를 사용하는 것이다. 여기서 알수 있는 것은 한쪽의 상대를 안다고 다른 쪽의 상태를 알 수 있는 것이 아니라는 점.

proxy는 새로운 연결을 맺는다는 것인데, 프록시 및 크라 서버 간 상태가 다 다를 수 있는데, 이벤트가 생기지 않는 한 상태 머신이 바뀌지 않기 때문에....

 

연결 종료법도 중요한데, fin ack = 정상 종료 의미하는 걸 줘야 한다. 애플리케이션 반드시 close를 콜 해줘야 한다 오...

그럼 여러 구조체들이 발생하게 되는데...그렇게 하지 않으면 리소스 안정성에 해가 되기 때문에..

 

좀 까다롭고 중요한 게 바로 혼잡 제어. 지금도 심각한 문제라 네트워크 문제 탑텐에 이게 들어가는 것이다.

여러 이유로 발생할 수있다. ack을 줘야 한다던지(=>손실발생), rtt를 너무짧게 추정했다던지, 혼잡 flow control

라우터 용량을 2명 이상 쓰기 때문에 여기서 타임아웃 등등등 각종문제 다 생긴다. 또 갈수록 딜레이도 길어지고..

때문에 throughput도 뚝떨어지고... 계쏙 중복도 나오고... 

 

혼잡제어 방법은 2가지 뿐. 송신자와 수신자가 메시지를 통해 합의를 보는 것(혼잡제어와 관련된 값들을 보고 체크한 뒤 맵/?? 을 잡는다 즉 현 상황을 추측한다) - 이게 티시피가 쓰고 있는 방법.

또 다른 방법은 네트워크 장치 측에서 이를 모니터링 하면, 이것들도 도움을 줄 수 있음.tcp보다 확장된 프로토콜이 있어, 네트워크 장치들이 호스트들에게 이에 대한 정보를 따로 알려준다. 이러면 좀더효율적으로 할 수 잇긴 함

 

혼잡제어의 기본이 되는 알고리즘은 AIMD. 증가는 하나씩 증가 시키는데, 깔 때는 계속 반띵하는 것. 그래서 그래프 보면 톱니바퀴처럼 생ㄱㄴ것. 로스 날 때마다 반씩 줄이고... 리시버가 센더로부터 바로바로 응답 못받을 때마다 이게 수시로 조정되는 것이다.

사실 여전히 연구가 되고 있는 분야다.

혼잡 제어 윈도우를 사용한다. 항상 처음에 윈도우를 1씩 하고, throw하기 시작하는 것. 좋은 네투=ㅡ워크에선 지수적으로 이게 증...?가...?할수있는데.. 그때마다 cwnd가 계속 줄어듦. 이건 빅데이터를 전송할 때 영향 줄수있으나, 로컬 내에선 이런것들이 잘 동작한다고 가정하고 또 실제로 별 문제 없기 때문에, 이럴땐 바이트 소모 하더라도 내부적으로 잘 할 수 있음.

 

또 threshold를 둬서, 얼마 이상으론 안가게 만든다던지 하는 방법이 있다.

tahoe 모델과 reno 모델(유한 상태 머신 종류임) 있는데, tcp는 후자를 주로 많이 쓴다.

 

그럼 이러한 것들이 fair 하나? 연결 개수 별로 병목 지점을 조절하는데.. 이게 fair 하다고 한들, 한번에 하나씩만 연결해서 나쁘다..?

애플리케이션 당 1개씩 tcp 쓴다 고하면 대부분의 경우 fair 하다 생각할 수 있다. 하지만멀티미디어 같이 대량의 데이터를 유량 제어할 상황이라면, 파일 다운로드 받는 것ㅅ 아닌 이상 그만큼 많이 쓰지도 않는데 많이 쓰니까 fair 문제에 걸리는 거다.

 

예를 들어 하나의 앱이 9개의 연결 갖고 있을 떄(말이 되나)?, 

 

암트 ㄴ이런 문제들 떔에 혼잡 제어 부분이 해결되는추세가 아니고 약화되는 추세다 오히려. 이런 문제 때문에 구글이 http3 같은 걸 만드는 경향이 있는 것. 그럼 이제 고민을 해야 함. 보통 인트라넷에선 혼잡 제어를 다 공유하진 않고, 이건 용량 설계 문제이므로 이건 회사의 문제.

그러나 유량 제어는 다르다. 서버랑 클라가 고민을 해야함. 서버? 클라?가 거의 송신자 역할을 하기 때문에 이에 대해 고민을 해야하는데, 데이터 받든 말든 난 꼭 데이터 받고 말겠어. 이런거면 유량 제어가 안되는 프로그램인 것.

 

그럼 msa는 어떤가? 이건 서버가 서버를 콜하는 건데 말이다. 빅데이터면 네트워크 파일 시스템을 사용하는데 이런ㄱ ㅕㅇ우는 또 어떨 것인가(비잔틴 문제 등 떄문인가..?)

 

뭐 로스가 발생한다, 유랑제어가 안되는 것 같다, 등의 정보를 알려주는 걸 서로 약속해서 이에 대한 값을 주고 받는 일이 필요할수있다. 이게 유량 제어의 핵심이다.

 

혼잡제어는 주로 밖으로 나갔을 때생기는 문제. 내부망이 아닌 방화벽 등을 포함한 외부망으로 나아갈 경우 이에 대해 고민해야 함.

공동 클라우드라던지... 애플리케이션 관점에서의 혼잡제어가 필요할 수 잇다. 그러나 이건 우리가 어떻게 하기어려운 문제다. 때문에 구글이 http3를 ... 이걸 써서 상위 레벨로 제어 로직을 올리는 방법도 하나가 될 수 있겠다.

그러나 누가 패킷을 씹어 먹어버리는 문제도 있어서...

우리가 많이 쓰는 것들은 그렇지 않은데... 이를테면 adid가 아무 고객사가 주요 뭐에 붙어서 통신하는데(디게 안좋은 네트워크) 근데 데이터를 1테라씩 주고받아야 한다던지.. 그런 문제가 생기고 있다.