안녕하세요 널널한 개발자님! 예전에 게임을 할 때 "랜선을 뽑고 5초 동안 무한 클릭 → 다시 연결하면 입력이 한꺼번에 서버로 전달되는 것처럼 보이는 현상"을 경험한 적이 있습니다. 제가 헷갈리는 부분은 다음과 같습니다: 버퍼링 영역 입력(클릭) 버퍼는 애플리케이션 레벨에서 관리되는 것인지, 아니면 TCP/UDP 자체에서 지원하는 것인지 궁금합니다. UDP 자체에는 순서 보장이나 재전송이 없는데, 그렇다면 "클라이언트 애플리케이션이 버퍼링을 했다가 복구 시 몰아서 보내는 구조"일까요? TCP와 버퍼 TCP도 송신 버퍼/재전송 메커니즘이 있으니, 이론적으로는 일정 시간 동안 못 보낸 데이터를 나중에 한꺼번에 보내는 게 가능할 것 같습니다. 그렇다면 "버퍼만 있다면 TCP에서도 동일한 효과"가 가능한 걸까요? 아니면 이런 식의 입력 버퍼링은 UDP 환경에서만 가능한 건지, 구분이 궁금합니다. 정리하자면 👉 애플리케이션 레벨 버퍼링이냐, TCP/UDP 레벨 버퍼링이냐 👉 TCP에서도 '랜선 뽑았다가 꽂으면 입력 몰아 보내기' 같은 현상이 가능한가? 이 부분을 명확히 알고 싶습니다. 예전에 메이플이라는 게임을 했을 때 위와같은방식으로 사람들이 몰리는 상점에 저렇게 뚫어서 들어가는게 유행했었거든요!
강의에서 소개해주신 TCP 장애(Re-transmission, Out of order)에 관해서 질문 드리려고 합니다. Server와 Client구조에서 Server는 Client에게 1~100을 송신한다고 하면 (TCP 통신) 통신 장애(Re-transmission, Out of order)가 발생한 경우 Client는 1, 2, 3 ... ,100을 순차적으로 받지 못하고 1, 2, 3, 3, 5, 4 ... 99, 98, 100이런 식으로 값을 받을 수 있다고 강의에서 설명해주셨습니다. 그리고 위와 같이 통신 장애가 발생하면 TCP, 즉 L4 layer에서 통신 장애가 발생한 부분을 자동으로 처리(후처리) 해준다고 말씀하셨는데, 그렇게 TCP layer에서 후처리 해주면 Client는 값을 정상적으로 받게 되는 건가요? 추가로 이런 보정 작업이 100%로 Client가 값을 정상적으로 받는 것을 보장해주는 것인지 궁금합니다 지식이 부족해서 명확하게 질문드리지 못한 점 정말 죄송합니다. 강의 잘 보고 있습니다. 감사합니다!
강사님 안녕하세요! 강사님 수업 들으면서 나날이 네트워크 지식이 깊어지고 있어 감사할 뿐입니다. 제가 Transport 계층 개념 추가 강의를 듣다가 UDP 통신에 관해 의문이 생겨서 질문 남깁니다. 우선 강의에서 위 그림을 잘못된 것이라 하셨습니다. 저기서 밑에 Response는 다 지워야 되는 게 맞는거라 하셨는데 여기에 의문이 있습니다. 실시간 통신에서 UDP 방식을 쓴다 하셨는데 예를 들어 저희가 네이버에서 실시간 축구 중계를 보기 위해 "중계 시청" 버튼을 클릭하면 그게 Client가 Server에게 "축구 보게 데이터 좀 "라고 Request 요청을 보내는 거라 생각합니다. 그럼 서버가 요청을 받아 클라이언트에게 축구 중계 데이터를 일방적으로 계속 빠르게 데이터를 주는 게 밑의 Response 화살표라고 생각합니다. 제가 생각하는 부분에 있어서 기술적으로나 논리적으로 틀린 게 있을까요?
만약에 3번 ACK를 보내고 이제 데이터를 전송하려고 하는데 그때 서버와 연결이 끊기면 데이터가 안가나요?? 그리고 약간 이런 맥락인 것 같은데 맞나요? 1번 SYN : 클라와 서버를 연결을 해달라고 요청 2번 SYN+ACK : 요청 잘 받았고(ACK), 나도 이제 연결해달라고 요청(SYN) 3번 ACK : 서버의 요청을 잘 받았음을 알림 이제 연결된 상태이고, 이후 데이터 전송
" 전송계층은 두 응용 계층 사이에서의 process-to-process 통신을 제공한다. 전송계층은 응용계층으로부터 메시지를 받아 전송계칭 패킷으로 캡슐화하여 전송한다" 라고 하셨는데, 제가 헷갈리는 부분이... 원래 TCP/IP 모듈을 보면 응용계층에서 데이터를 캡슐화하면서 Physcial layer 물리계층에 도달하면 0과 1의 신호가 돼서 다른 컴퓨터로 전선으로 전송이돼서 데이터를 받은 컴퓨터에서 다시 decapsulation을 거치면서 원본 데이터를 응용계층에 전달하는 것으로 알고 있는데요 전송 계층에서는 3way handshaking을 통해 두 컴퓨터의 transport 계층 사이에 논리적인 연결을 구축해서 데이터를 주고받는 것이라면... 아래의 network, data, physical layer은 거치지 않고 곧바로 주고받는 것인가요??? 그럼 어떤 상황에서 전송계층을 통해 곧바로 주고받고 어떤 상황에서 physical layer까지 도달해서 전달하는지 궁금합니다
Transport Layer의 특징에서 "연결 지향 데이터 스트림 지원" 이라는 항목이 UDP는 비연결성에 데이터그램 방식 통신이므로 해당되지 않고, "신뢰성" 항목에 UDP는 신뢰성이 보장되지 않기 때문에 데이터 손실 가능성이 있으며, "흐름 제어" 항목에 UDP는 TCP처럼 receiver가 sender에게 window size를 보내는 방식이 없기 때문에 흐름제어가 되지 않는다고 알고있습니다. Transport Layer의 특징이 아닌 TCP의 특징으로 알고있으면 되나요 아니면 제가 틀리게 알고있는건가요
tcp가 ip 프로토콜에서는 제공하지 않는 오류제어, 흐름제어, 혼잡제어를 제공하는 신뢰성있는 연결지향 프로토콜이라는 것을 알았습니다. tcp가 handshake과정을 통해 연결설정을 하는 것이 결국 오류제어, 흐름제어, 혼잡제어를 제공하기 위한것인가요? 연결설정과정 없이는 신뢰성 있는 서비스를 제공하지 못하는 것인지 궁금합니다. 그리고 왜 tcp는 비용을 감수하면서 연결설정 과정을 거치는 것인지 명확한 설명을 듣고 싶습니다.
[질문 내용] 안녕하세요. TCP 프로토콜을 공부하다 궁금한 점이 있어 질문드립니다. 연결지향의 특징을 갖는 TCP는 연결할 때 뿐만 아니라 해제할 때도 4-way handshake라는 과정을 거친다고 알고 있습니다. 4-way handshake는 언제 이루어지는 것인가요? 연결을 종료하는 시점이 말씀하신 데이터 전달 보증 과정이 종료되면 일어나는 것인지 궁금합니다..
안녕하세요! 먼저 강의 잘 들었습니다 강의보고 따라해보니 CRUD 프로그램 개발에는 조금이나마 이해가 됩니다 그런데 socket을 이용하여 tcp 통신을 해야하는 프로젝트를 진행중인데 nest.js 공식 문서를 보니 @SubscribeMessage('event_name') 을 이용하여 데이터를 받고 emit을 이용하여 event_name으로 주는 환경이더라고요?? 현재 서버를 nest.js 기반으로 개발하고 개발해 놓은 클라이언트(c++작성)에서 tcp 통신을 하기 위해서는 c++ 클라이언트에서도 socket.io를 활용하여 event_name 을 통하여 통신을 해야하는 것인가요? 아니면 event_name 없이 단순 tcp 통신을 통해 binary 데이터를 주고 받을 수 있는 서버 nest.js 환경이 있을까요?? 제가 socket.io에 대해 이해한 내용이 맞는건지도 잘 모르겠지만 답변 부탁드리겠습니다!
안녕하세요. 수강중에 첫 질문 남기게 되었습니다. h2 db의 웹 콘솔에서 jdbc url을 jdbc:h2:~/test에서 jdbc:h2:tcp://localhost/~/test로 바꾸었습니다. 강의에서는 파일에 접근할 때, 웹 콘솔이나 DB등 복수의 앱에서 접근하면 충돌이 일어날 수 있기 때문에 TCP프로토콜을 통해 이를 방지할 수 있다고 하셨습니다. 이때 TCP 소켓이 어떻게 복수의 앱 접근에 대한 충돌을 방지할 수 있는 것인지 궁금합니다. 덕분에 잘 배우고있습니다. 감사합니다.
[질문 내용] TCP 강의 중 TCP/IP 연결은 클라이언트와 서버가 서로 SYN,ACK를 주고 받아서 개념적으로만 연결이 됐다고 설명하셨습니다. 그 이유는 클라이언트와 서버가 연결을 할 때, 중간에 수많은 서버(노드)들을 거쳤는지를 잘 모르기 때문이라고 설명하셨습니다. 그러면 여기서 궁금한점은 클라이언트와 서버가 중간 노드들을 거쳐서 SYN,ACK를 주고 받는게 아닌건가요?? 만약 중간 노드들을 거쳐서 주고 받는거라면 "중간 노드들이 잘 연결이 됐기 때문에 SYN, ACK를 주고 받은게 아닌가??" 라는 생각이 들어서 질문을 남기게 됐습니다!
12:46에서 TCP라는 걸 그대로 두고 UDP에 손을 대면 된다 라고 설명해주셨는데요. TCP 와 UDP는 별개여서, TCP를 쓰든 UDP를 쓰든 결정해야하는 걸로 생각하고 있었는데, "TCP라는 걸 그대로 두고 UDP에 손을 대면 된다" 라는 건.. TCP는 늘 기본적으로 쓰는 것이고 UDP는 거기에 부가적으로(additional하게) 사용하는 건가요? +) 여력이 되신다면 하나 더 답변 부탁드립니다. UDP 특징 정리 부분에서 "애플리케이션에서 추가 작업 필요"라는 내용이 잘 감이 안오는데 조금더 설명주실 수 있을까요?
