두다지 서버 개발자 양성 프로그램 Week 7

두다지 서버 개발자 양성 프로그램 Week 7

7번 째 멘토링

컴퓨터 네트워크의 단골 손님인 OSI 7계층에 대한 전반적 이해와 Application Layer를 학습한 후, 학습한 내용에 대하여 리뷰하는 시간을 가졌다. 멘토링 시간을 위해 컴퓨터 네트워크라는 과목을 다시 학습해보니 작년에 수업을 통해 배울 때 보다 양이 더 방대하게 느껴졌고, 세세한 이해를 필요로 하는 부분이 많아 한 계층만을 학습하는데에도 오랜 시간이 소모되었던 것 같다. 멘토님께서는 네트워크 전문가로의 길을 갈 것이 아니라면, 각 계층의 특징과 계층 간 이동의 flow를 이해하는 정도로 충분하다고 하셔서 심도 깊은 이해보다는 각 계층에 대한 특징에 초점을 맞추고 학습했던 것 같다. 그리고 멘토링 시간을 통해 멘토님께서 그림을 통해 네트워크의 전체적 전송 flow를 잘 설명해주셔서 이해에 더 도움이 되었다.

학습한 것에 대한 리뷰

• 네트워크는 정보 전달에 가장 큰 목적이 있음
• 실생활의 '등기우편'도 컴퓨터 네트워크와 같은 개념
  • 상대방이 잘 수령했는지 여부까지 알 수 있는 송신법
  • 분류 과정에서 각 branch는 자신이 관심 있는 부분만 본다!
• 각 계층 역시 패킷의 내용 중에서 관심있어 하는 '특정' 부분의 정보만을 선택해서 보는 것
• Socket은 일종의 Module이자 API
  • 프로세스 내에 존재하는 것이며, User가 Queue에 쌓인 데이터 상황을 보며 사용
    
    

Computer Network

• CSMA/CD는 같은 LAN에 물리는 host간 경쟁적으로 LAN선 사용하기 위한 방식
• 같은 LAN선에 물린 host들 간에는 서로 패킷이 공개되는 문제가 있을 수 있음
  • 네트워크 카드까지 해당 패킷 들어오나, 운영체제단에서 header(dest IP) 확인하고 Drop 혹은 Take
  • 커널 튜닝을 통해 같은 LAN선의 데이터 모두 Sniffing 가능할 수도 있음
• 같은 LAN선에 물린 host들 간 데이터 전송은 LAN 하나에서 모두 처리되기 때문에 빠를 수 밖에 없음
  • 따라서 서버 간 데이터 전송이 잦은 host들은 같은 LAN선에 물리게 네트워크 설계
• Switch는 대개 그저 자신에게 가장 가까운 Router에게 패킷 전송
  • Router가 RIP 등의 프로토콜 통해 Routing 수행
• ISP 간 통합이 되지 않기 때문에 Routing의 효용이 떨어짐(ISP is for business)
• 자기 자신에게 온 패킷을 받지 않는 경우도 있을 수 있음
  • 받고 싶을 경우, Listen을 수행해야 함
  • Port의 개념이 등장한 이유
    • 해당 Port number로 전달된 패킷만 허용하겠다는 의미
    • 항상 destination 주소와 Port number가 함께 움직임!
    • 기본적으로 HTTP의 경우 80번 Port를 default Port number로 사용
• UDP의 특징: 아예 못 받거나, 보낸만큼 다 받거나
  • 패킷의 수신 순서를 전혀 알 수 없음
  • Streaming Service, Interactive game에서 캐릭터의 위치 정보 등에는 사용하기 좋음
    • 즉, 마지막 패킷 정보가 중요한 서비스에 적합
• 그러나, 대부분의 경우가 그렇지 않음 -> 'TCP를 사용해야하는 Case들'
• TCP는 받는 쪽에서 일정 Port number로 Listen을 하고 있음
  • 보내는 쪽은 TCP Connection 확인(3-Way handshake)
  • 연결되면 이후부터 패킷 전송
• Connection은 양측에서 socket을 생성하는 상황
  • 각 Socket은 내 IP 정보, 상대 IP 정보를 담고 있음
  • Client는 Server로 부터 어떠한 Port number로 전송할 것이라는 정보를 받음
    • 1. C -> S : 나 TCP Connection 할래
    • 2. S -> C : 그래. 나는 너에게 정보를 보낼 일이 있으면, '9999' Port number로 정보를 전송할게
    • 3. C -> S : 알겠어. 지정해준 Port number도 확인했어
• 그러나 TCP Connection 이후에도 Dead Connection의 문제가 있을 수 있음
  • heart beat packet을 보내는 이유
  • heart beat의 확인을 통해 연결이 still alive 상황인지 확인할 수 있음
• 전송하고자 하는 패킷이 너무 크면 번호를 붙여 Packet을 나누어 전송
  • socket.write(2048)하면 실제로는 규약에 따라 일정 크기(ex. by 128 bytes)로 나누어 번호를 붙여 전송
  • socket.read(2048)하면 buffer에 채워진 정보를 읽어올 수 있음
    • socket.read(1024)하면 buffer의 앞 부분을 읽어오게 됨
    • socket.read(10000)하더라도 2048 bytes 만큼만 보여줌
• 전송 과정에서 패킷 유실의 문제도 있을 수 있음
  • TCP의 flow control을 통해 순서가 보장된 buffer를 전송 받을 수 있게 됨
  • Go back N, Selective Repeat 등의 알고리즘을 통해 순서 회복 가능
• 받는 쪽에서의 해석이 중요하기 때문에 인코딩, 디코딩 개념이 등장
  • 우리는 어떻게 보내겠다라는 약속을 해야 함
  • 1. Parser를 이용
    • 서로 보낼 정보가 무엇인지 아는 가정하에 특수문자 등을 이용하여 전송
    • ex) A, 90, 80, 70 / B, 90, 50, 60
  • 2. 각 정보를 전송 크기 만큼 채워서 전송
    • ex) A, 90, 80, 70
  • 3. Application header에 Packet key값과 길이 정보 전달
    • 특정 길이만큼은 해당 key값에 들어가야하는 정보라고 명시
• JSON의 경우 줄바꿈을 기준으로 Parsing
  • JSON.parse()는 socket.readline()와 같은 개념
  • 성능이 뛰어난 방법은 아니지만 굉장히 편리하고 유연하기 때문에 널리 사용
• HTTP도 status code, header code 그리고 body code를 줄바꿈을 기준으로 parsing
  
  

다음 주 까지의 assignment

• UDP 소켓 프로그래밍으로 TCP 구현
  • UDP로 보내지만 TCP와 같이 동작하도록!
  • socket과 buffer 사용
  • FakeRouter도 하나 생성 -> 하나의 Process
    • 정해진 길이만큼 Router에 write
    • Router는 일정 확률(5-10%)로 Packet Drop
    • 이후 TroubleShooting(flow control, sequence..)
  • Magic Port Number(ex. 50000) 사용
• Transport Layer, Network Layer 정리