유튜브,강의 잘 보고 있습니다! 다름이 아니라 한가지 궁금한 점이 생겨서 질문드립니다! 제가 프로젝트를 진행하며 SSE(Server Sent Event) 라는 기술을 이용하여 사용자에게 특정 이벤트 발생 시 푸시알림을 주는 부분을 구현한 적이 있습니다 당시에는 문제없이 동작하여 대수롭지 않게 넘어갔지만! 네트워크 , http를 공부하며 든 생각인데.. SSE는 http의 persistence connection이라는 것 덕분에 가능하다라는 것 까지는 도달했으나 여기서 든 궁금증이 기존에 제가 가지고 있는 정보가 톰캣 서버는 기본적으로 따로 설정해주지 않으면 쓰레드풀을 200크기 만큼 가진다. 연결이 지속되어 있기 때문에 요청이 오지 않았지만 이벤트가 발생하면 해당 호스트에게 푸시알림이라는 형태로 응답이 가능하다. 여기서 연결이 지속되어 있다는 의미는 연결을 지속하기 위해 쓰레드가 반환되지 못하고 있음을 뜻한다고 생각하는데 그렇게 되면 특정 케이스에서 모든 쓰레드가 연결지속을 위해 반환되지 않은 상황이라면 다음 요청에 대해서 응답할 수 없어 큐에서 대기해야만 하는 상황이 생기는 것인가? 하는 궁금증입니다. 단순히 이런 상황일 때 쓰레드풀에 쓰레드더 만드나? 라는 생각은 컨텍스트 스위칭 관련해서 복잡한 문제라 쓰레드 숫자를 마음대로 하지는 않을 것이라 생각되고 제가 생각한 문제가 맞다면 SSE로 실제 서비스하는 곳은 없지 않을까..? 라는 생각이 들고 프로젝트에 대한 아쉬움이 조금 남아서.. 폴링 방식처럼 계속 서버에게 이벤트가 발생되었는지 확인하는 방식이 차라리 더 나을 수 있다는 생각도 들어서요!
3-11 WLAN 실습 중, PC0에서 무선 라우터를 거쳐 유선 라우터까지, 라우터에서 서버까지는 연결이 잘 되는데, PC에서 서버까지는 연결이 잘 되지 않습니다. 비슷한 문제로, 3-12 VoIP 실습에서 VoIP 설정 전에 RIPv2를 적용해서 PC0->R1, R1->PC1은 연결이 잘 되는데 PC0->PC1은 핑이 가지 않습니다. 왜 이런 현상이 생기는 건가요?!
자료 5pg를 보면 첫번째 라우터는 192.168.10.254와 192.168.20.1로 부여 했습니다. 또 두번째 라우터는 부여된 ip가 192.168.20.254와 192.168.30.254로 부여되어 있는데...ip 라우터는 해당 범위 내의 장치(컴퓨터등...)에 지정된 ip를 제외한 아무 ip나 부여해도 되는건가요? 예를들어 첫번째 라우터가 네트워크 1에 해당하는 192.168.10.233도 ip 부여가 가능한가요?
패킷이 인터넷 세계로 나온 다음 remote host로 전달되기 까지 정말 수 많은 라우터들을 만나게 될텐데, 거미줄처럼 엮여있는 수많은 라우터를 헤치고 어떻게 remote 까지 도착하게 될까요?? 라우터는 L3이고 그 다음 라우터로 도착할때까지 오직 IP 주소만으로 식별하여 해당 라우터에 패킷을 보낼 수 있는 건가요?? 이 라우터들은 서로 물리적으로 연결되어 있지 않을 텐데 그렇다면 어떻게 상대방의 라우터의 위치를 식별할 수 있는 것인가요?? L2 수준에서 ARP를 사용해 mac 주소를 파악했던것과 같은 이치일까요??
지금까지 제가 이해한 네트워크 흐름은 이렇습니다. 로컬 프로세스에서 Socket에 IO를 통해 Stream data 생성 (브라우저라면 HTTP Request를 Stream으로 TCP에 전달하겠군요) OS 수준인 TCP에서 일련의 Stream data를 Segment들로 분할하며, 이때 TCP 헤더에 Remote Endpoint의 Port 번호가 추가 TCP에서 받은 Segment를 Packet에 캡슐화. 이때 Source IP와 Remote IP가 Packet 헤더에 추가 L4에서 Packet을 Frame으로 캡슐화. 이때 자신이 속한 사설망의 L2 Switch의 mac 주소가 Frame 헤더에 추가 Frame이 pc의 NIC를 출발하여 L2 access에 도착 L2 access에서 L2 Distribution으로 Frame 전달 (없을 수도 있겠네요) L2 Distribution에서는 Frame을 디캡슐화하여 패킷을 확인하고 해당 패킷의 Source IP를 자신의 public IP로 변환 후 인터넷 세계로 패킷을 전송 ... 8번 과정부터 머릿속에 잘 그려지지 않는데, 인터넷 세계에서 해당 패킷이 가고자 하는 remote host로 가기 위해서는 어떤 과정을 거치게 되나요??? 이 세상에는 ipv4 갯수만큼 엄청나게 많은 라우터들이 존재할텐데 말입니다... ARP가 그러했듯 라우터들끼리 미리미리 주변 라우터가 어디에 있는지 broadcast로 파악을 해두고 있는 것일까요?? 그리고 인터넷에서는 remote host가 속한 사설망에 패킷이 도착할때 까지는 L3 끼리만 스위칭을 하게될까요?? 각 라우터들도 자신만의 사설망에 속해 있을 것이고 그렇다면 자신이 관리하는 L2 스위치도 있을 것인데, 패킷이 remote host로 전달되느 ㄴ과정에서 L2, L3, L2, L3 로 번갈아가면서 전달되지 않을까라는 생각이 듭니다.
라우터가 MTU 용량을 다 받을 수 없을때 단편화가 이루어져서 보내지고 단편화 현상을 해결하기위해 보낼때부터 사이즈를 낮춰서 보낸다고 하셨는데, 그러면 처음부터 라우터(패킷의 이동경로)의 경로를 알고 있는걸까요? 아니라면 어떻게알고 다음 라우터로 넘어갈때 사이즈를 낮춰서 보낼수 있을까요?
이전 강의 중 Stream에 대해 설명해주셨을때 크기가 큰 Stream을 TCP에 넘겨줄때 MSS에 따라 segmentation이 된다라고 이해했습니다. 그런데 "TCP 연결 과정"에서도 Client와 Server의 MSS가 다를 때에도 낮은 MSS에 맞춘다고 이해했습니다. 강의 예시처럼 Client의 MSS가 1460, Server의 MSS가 1400일때 Server의 MSS에 맞춰버린다고 하면 이때 어느 부분에서 일어나는 건가요? SYN+ACK를 통해 server의 MSS를 받고 L2->L3->L4(TCP)로 가서 한번 더 segmentation이 일어나는 건가요? 3-way handshaking을 할때에도 en/decapsulation이 일어나는게 맞는가요?
강사님. 안녕하세요. 강의 잘 보고 있습니다. 궁금한게 있어서 질문 드립니다. 연결 종료 과정에서 그림을 보면 FIN+ACK을 같이 보내고 있는데 그 이유가 무엇인가요? Client ------FIN+ACK?-------> Server Client <--------ACK----------- Server Client <-----FIN+ACK?-------- Server Client ---------ACK----------> Server ACK은 전에 보냈던 데이터를 잘 수신했다는 의미로 보내는 것이라 이해를 했는데, FIN을 처음 보낼 때 같이 ACK도 보내는 이유가 궁금합니다.
로컬 pc에서 인터넷과 통신하기 위한 게이트웨이의 mac 주소를 알기 위해서 ARP Request를 Broatcast 보내고 ARP Reply 응답을 통해 해당 게이트웨이의 mac 주소를 전달받는다고 설명해주셨습니다. 그렇다면 ARP Request가 전달되는 범위는 request가 uplink 하면서 처음 만난 gateway 까지가 되고 그 이상으로 broatcast를 보내지 않고 drop 하게 되는 건가요?
