startup-7days

79017738937572

TCP/IP 관련되어 처음 접근 하시는 분들이 실수 하시는부분 몇가지입니다. LAB 환경에서만 제대로 된다고 실제 환경이 되면 다양한 상황이 될수가 있습니다. 그래서

1. 소켓은 무조건 ASYNC 소켓으로 작성을 하세요. 이건 CONNECT 분만 아니라 송수신에서도 중요합니다. ASYNC 소켓은 함수 리턴값이 아니라 에러코드값으로 판단하면 됩니다.

2. 송/수신은 반드시 지정된 크기가 전송될때까지로 해야 합니다. 즉, 100 바이트 전송을 send 함수로 넘겨만 주었다고 무조건 100 바이트 전송이 이루어지는건 아닙니다. 90바이트 10바이트 전송이 가능합니다. TCP/IP 통신은 전송을 게런티 해주지, 전송 시간(지금 당장)까지 게런티 해주는게 아닙니다.

이 모든것들은 통신이라는것이 중간에 여러 통신 기기(주로 라우터)들을 거쳐서 이루어 지기 때문에 이곳에서 우선권(QoS 등등)을 지닌 패킷과 MTU 크기등에 따라 프레그먼트가 발생하게 됩니다. 즉, A --- > B --- > D 라우터를 통하는게 아니라 A--- > B, A--->C B-->D , C--->D 이런식으로 패킷이 분리되어 전송이 가능한것입니다. 에플리케이션 레이어에서는 몰라도 되는것이지만 이상한 상황이 발생한다면 대부분 이곳에서 발생하는 것이기에 1,2번은 반드시 지키면서 하시면 큰 무리는 없을겁니다. 자신만의 ASYNC 소켓과 (주로 접속 관련) 전송 함수들을 만들어 놓으면 평생 사용하시면 됩니다.

L3 쪽에 관심이 있으시면 WIRESHARK 같은거 켜놓으시고 IP/TCP 헤더 부분만 잘 보셔도 큰 도움이 되실겁니다. ^^

[지리산 ㅡ구달수] [오전 12:07] 이해하면 인생이 바뀌는 TCP 송/수신 원리 - https://youtube.com/watch?v=K9L9YZhEjC0&si=ybN1mUuwg2kh4_PT

[지리산 ㅡ구달수] [오후 12:31] 출처: 자바실험실 https://share.google/tVuwBGVybIoHsF5BE

00:46 TCP/IP 연결　02:10 Socket 통신의 Receive와 Send　03:49 송신측 전송과정　04:45 메모리의 64KB Read　06:57 Buffered I/O와 분해　09:42 직소퍼즐의 비유　12:31 Packet과 Frame　16:16 수신측 전송과정　21:11 ACK　22:17 ★ Wait와 TCP의 속도 지연　23:38 TCP Buffer의 Window size　24:28 ★ 서버측의 Send와 Wait 결정　26:36 Read 속도와 Network 수신 속도　28:50 ★ Window size 확인　31:12 정확한 원인 파악

대략 Segment가 두 개 정도 오게 되면 즉시 다음 차례인 3번을 보내는 게 아니고 ACK#3이 올 때까지 Wait를 한다. 여기서 속도 지연이 발생한다. TCP가 UDP보다 느린 이유 중의 하나이다. TCP Buffer의 크기는 Window Size라고 불리는데 수신 측에서 Segment가 날라오면 조립해서 넣을 수 있는 공간을 의미하며, ACK를 보낼 때 Window Size를 포함하고 있다. 수신 측의 Window Size가 MSS보다 크다면 3번을 보내고 그렇지 않다면 Wait가 걸린다. TCP Buffer에서 File I/O Buffer로 Segment를 빨리 퍼올리지 못하면, (즉 Read속도가 Network수신속도보다 느리면) TCP Buffer의 여유공간은 점점 줄어들게 될 것이고 Wait가 걸려서 속도지연이 생기게 된다..! 그림으로 그려주시면서 상세한 과정을 택배에 빗대어 설명해주시니까 도움이 많이 됩니다

ACK , Wait , TCP buffer -> File IO buffer 로 read하는 속도 , 수신측의 window size 이 4가지의 관계에 대해서 배웠네요. 또한 wait의 존재 때문에 TCP 와 UDP의 속도 차이가 난다는 사실 도 배웠습니다.

포트 스캔시, 자기 머신이 syn패킷 보낸뒤에 IMCP프로토콜에 의해 error 패킷이 나가서, 자신의 IP주소를 바꿔도 노출된다다라고! 해서, 자신의 방화벽 outgoing packets 룰 좀 조정해보고싶어, 어제부터 TCP 프로토콜 공부하는데... 그러다가, 이 동영상을 봤네요! 동영상 좋네요! 와~~~ TCP/IP 쓰이는 프로토콜 매우 많네요! 동영상에서 Stop and Wait, Go Back N (sliding window), Selective Repeat 프로토콜들을 말씀하시는것지요? 레이어 2계층, 데이터 링크 프로토콜들인데,,, TCP/IP(+ ipv4)는 모든 레이어계층의 프로토콜들을 고루 쓰네요! 보안쪽은 공부해야할 프로토콜들이 많네요! 간략적인 개요만 알고는 문제해결을 못 할것 같은...

서버 측 flow: 1. 클라이언트 측에서 "파일 다운로드" 요청 2. 서버에서 TCP/IP 연결이 되었을 경우, 소켓 통신 가능 3. 소켓은 File의 형태이기에 Process에서 이 File인 소켓한테서 "Receive, Send"를 할 수 있음 4. 클라이언트의 요청을 "Receive"로 받아서, 요청을 "읽고", 5. 해당 요청이 이제 "파일 다운로드"이니, 해당 파일을 SSD, HDD 등의 메모리에서 찾아서 Device Driver와 File System을 거쳐서 6. 서버 프로세스가 할당된 메모리, 즉, 버퍼에 64KB 씩 잘라서 넣는다. 7. 이런 64KB 씩 자른 파일을, 소켓 통신을 통해서 TCP로 보내게 되는데, 8. 소켓(Application 영역) 영역 에서 TCP Buffer로 Send를 한다는 말이다. 9. 이렇게 Send를 할 때, COPY를 하는 것이다. 10. TCP Buffer에서는 이제 COPY가 되어 있는 상태이고, 11. 이제, TCP -> IP로 내려갈 때, 분해가 일어나게 되는데, 12. 바로 Segmentation이 일어나서, 데이터들이 Segment로 잘게 분해된다. 13. 그 후 Packet으로 감싼다. -> 이렇게 이해하면 되나요?

1. Segment는 tcp level에서 쪼개질때 어떤 기준으로 쪼개지는걸까요? 일정한 크기 단위로 쪼개지나요? 2. Tcp buffer의 경우는 하드웨어적인 위치가 어디인걸까요? os내의 시스템이니 컴퓨터 램을 그대로 쓰는걸까요? 3. Tcp buffer는 process에서 그러한것처럼 connection별로 생성되는 것일까요 아니면 공유를 하나요? 만약 공유를 한다면 동시성을 어떻게 관리르하나요?

Process가 File에 할 수 있는 Operation : RWX 소켓에 대해 읽는다 -> Receive 소켓에 대해 쓴다 -> Send => 서버 프로세스가 Socket에 대고 IO를 한다 파일을 잘개 쪼개 버퍼에 올리고, 버퍼 내용을 복사해서 Send한다 => Buffered I/O 이때 Buffer에 담긴 쪼갠 파일도 Segment(4계층) 단위로 쪼개고, header를 붙여 Packet(3계층)으로 만들어 전송한다. 패킷은 논리적으로 End-to-End로 전송되지만, Frame 자체는 2계층에서 전송되며 최종 원하는 단말로 전송될 때까지 계속 갈아 끼워진다. MAC 주소를 활용한 동일한 물리적 네트워크 단위의 통신인 이더넷 프로토콜 전송이기 때문이다. 클라이언트에서 Segment를 받으면 다음 Segment 번호에 대해 요청으로 ACK를 반환한다. ACK 메세지에는 클라이언트의 TCP Buffer의 가용 영역인 Window Size를 포함한다. 사실 서버에서는 Segments를 보낸 상태에서 WAIT하고 있었다. 이제서야 잘 보낸 것을 확인하고 다음 Segment를 보낸다. 이러한 WAIT이 TCP 성능 저하의 원인 이러한 무작정 WAIT하는 전략의 성능 이슈를 막기 위해 등장한 전략이 있다. Window Size > Maximum Segment Size ? YES : NO(then Wait) Receive Process가 Socket에 대하여 TCP Buffer를 읽으면 Read 속도 > Network 속도 ? YES : TCP Buffer Size가 작아지며 처리 지연 현상 발생 따라서 처리 지연 문제 발생시 장애 원인을 Network가 아니라 프로그램 구조에서 찾아야 한다 !!일단 Process가 TCP Buffer를 읽는 속도가 얼마나 빠른지 확인하라. Network에서 수신하는 속도보다 무조건 빨라야 병목이 발생하지 않는다!!

http 통신이 소켓 통신의 한 종류라고 이해하고 있고(http는 tcp 위에서 만들어졌으니), 소켓 통신은 양방향, http 통신은 단방향(stateless)로 알고있습니다. 그럼 http 통신은 통신을 할때마다 소켓 통신 연결 -> 소켓 통신 종료를 반복하여 단방향 통신처럼 만든건지 궁금합니다! (만약 맞다면 3, 4 handshake 과정을 매번 반복하는건지도 궁금합니다!)