(Do it 네트워크, 2주차) 260302~260306

시작하며

벌써 3월이다. 네트워크 스터디는 이제 2주차를 맞이한다.

다른 스터디와 달리 3주라는 짧은 기간이다보니 벌써 반환점을 돌아버린 느낌이다!

스피디하다면 스피디할 수도 있지만 짧은 기간에 네트워크의 많은 개념을 정리하고 있으니 그래도 운동공부 많이 된다. 스트롱 스트롱. 다행히도(?) 잘 때 생각 많이 나거나 하진 않았다.

자 이제 1주차보다 많은 분량을 자랑하듯 보이는 2주차로 들어가보겠다.

 

먼저 이번 주 공부 인증부터.

2주차 공부 인증샷

 

6장. 광역 통신 방법

- 목차와 핵심 키워드를 먼저 훑어보니 3계층(네트워크 계층)에서 다룬 IPv4 프로토콜의 심화 과정이 될 것으로 보인다.

정보처리기사 같은 자격증 시험에서도 그렇고, 네트워크와 기본 컴퓨터 과학 분야에서 특히 IP가 갖는 비중이 큼을 짐작할 수 있겠다.

- ICMP 프로토콜이 정확히 무엇을 나타내는 지 사실 잘 몰랐다. 그나마 들어본 거로는 'Ping of Death와 같은 분산 서비스 공격(DDoS)에서 ICMP 패킷이 활용된다' 정도겠다. 아직까지는 CS 지식이 정보처리기사 필기 수준에 머물러 있음을 깨달았다.

이번 장에서는 ICMP 프로토콜에 대해 조금 더 자세히 알아갈 수 있을 것으로 기대한다!

- 라우팅 테이블은 사실 1주차 분량인 4장(네트워크 계층) 라우팅 부분에서 먼저 공부한 개념이긴 하다. 다만 당시에는 이게 정확히 어떤 건지 감이 잡히지 않았는데, 6장을 공부하고 실습하며 라우팅 테이블을 직접 눈으로 확인해보고 이해도를 높일 수 있었다.

(아래 실습 장면 참고)

6장 실습. 사진은 명령 프롬프트에서 netstat -r 명령어를 입력해 확인한 개인 노트북 라우팅 테이블이다. IPv4 경로 테이블의 '활성 경로' 부분이 컴퓨터의 라우팅 테이블이라고 한다. 라우팅 테이블은 IP 주소로 통신하는 컴퓨터나 네트워크 장치들이 가지고 있는, 목적지 IP 주소로 향하는 경로가 작성된 표다. 추가로 네트워크 대상과 네트워크 마스크는 목적지 IP 주소 대역, 인터페이스는 통신 대상 컴퓨터와 통신하기 전 나서야 할 내 컴퓨터의 출구 주소, 게이트웨이는 내 컴퓨터와 통신할 다른 장치의 기본 경로 주소라고 한다.

 

(6장 되새김 문제 풀이)

- 처음으로 문제가 굉장히 어렵다고 느꼈다. 6장을 적어도 두 번 이상 꼼꼼히 읽어야 풀 수 있을 정도로 특히 개념 이해와 응용력이 필요했다.

대학 때 오픈북 시험을 봤던 경험이 떠올라, 어려웠지만 재밌었다!

 

1. IPv4 프로토콜 길이가 20bytes -> 프로토콜에서 인터넷 헤더 길이 필드 값? 5
*인터넷 헤더 길이는 주로 5로 표기

2. IPv4 프로토콜로 1300bytes 데이터 전송 시, 프로토콜의 총 길이 필드 값? 1320
* 총 길이=데이터+상위 프로토콜+IPv4 프로토콜 크기(20)
* 문제에는 상위 프로토콜이 주어지지 않았으므로
데이터+IPv4 프로토콜 크기만 계산해보면 1300+20=1320

3. IPv4 프로토콜로 MTU를 넘는 데이터를 조각화해 보낸다고 가정
첫 번째 데이터를 캡슐화한 프로토콜 아이디: 1111
-> 나머지 데이터를 캡슐화한 프로토콜의 아이디? 1111
* 아이디는, 조각화된 데이터가 원래 하나의 데이터임을 입증하는 값으로 하나의 큰 데이터에서 쪼개진 각 데이터는 모두 같은 아이디 값을 가진다!

4. IPv4 프로토콜로 MTU를 넘는 데이터를 조각화해 보낸다고 가정 시 첫 번째 데이터 캡슐화한 패킷으로 보낸 데이터: 1480bytes
-> 두 번째 데이터 캡슐화한 프로토콜의 조각 오프셋? 1480 / 8 = 185
* 조각 오프셋은, 큰 데이터를 조각화해 보낼 때 여러 개로 쪼개진 데이터 순서를 의미하는 값으로 수신 쪽에서 이 값을 참고해 나뉜 데이터를 다시 원래대로 조립 -> 원래 데이터 크기 값을 8로 나눈 값에 해당!

5. IPv4 프로토콜로 보낸 패킷이 인터넷에서 영원히 떠돌아다니지 못하도록 하는 기능? TTL(time to live; 생존시간)
* TTL(time to live): '생존 기간,' 패킷이 네트워크에서 생존 가능한 기간으로, 하나의 패킷이 네트워크에서 영속성(영원히 존재하는 속성)을 가지지 않도록 함 -> 기본값으로. 윈도우는 128, 리눅스는 64
-> 프로토콜이 하나의 LAN을 넘어갈 때마다 1씩 줄어들며, TTL이 0이 되는 순간 해당 패킷 폐기(네트워크 장비 설정 오류로 잉여 패킷이 영원히 순환함으로 패킷을 처리하는 장비의 리소스를 낭비하는 상황을 방지할 필요 있음)

6. IPv4 프로토콜에서, 어떤 상위 프로토콜이 캡슐화되었는지 표시하는 '프로토콜' 필드에 들어가는 값으로 ICMP, TCP, UDP를 의미하는 값을 각각 쓰면? ICMP(1), TCP(6), UDP(17)

7. ICMP 프로토콜 통싱 시 확인할 수 있는 주요 유형값은?
1) 8: 통신 확인 요청
2) 0: 통신 확인에 정상 응답
3) 3: 목적지에 패킷이 정상적으로 도착하지 못힘(오류)
4) 11: 목적지에 패킷이 도착했지만 응답 시간 초과(오류)

8. 다음 라우팅 테이블에 따를 때, 목적지 IP 주소가 8.8.8.8이면 해당 패킷이 전송되는 위치는? 192.168.30.2
(라우팅 테이블)
0.0.0.0 -> 192.168.30.2
192.168.10.0/24 -> 192.168.10.2
192.168.20.0/24 -> 192.168.20.2
* 주어진 라우팅 테이블에서 0.0.0.0(네트워크 대상 혹은 네트워크 마스크로 예상)으로 시작하는 첫 번째 줄은 기본 게이트웨이 관련 내용을 나타냄
특정 목적지의 IP 주소로 통신할 때, 특정 예외 상황을 제외하고 어떤 IP든 우선 기본 설정된 게이트웨이 주소로 가도록 설정되어 있음
따라서 출발지에서 만들어진 패킷은 우선 기본 게이트웨이 주소인 192.168.30.2로 전송될 것!

9. MTU가 1500인 네트워크 장치들로 4000bytes인 데이터 전송할 때, 몇 개의 데이터로 조각화되고 마지막 패킷으로 보내는 데이터 크기는? 3개로 조각화, 마지막 패킷으로 보내는 데이터 크기: 1040
* 각 장치는 MTU인 1500 이상 크기로 데이터 전송이 불가하므로 우선 MTU보다 작은 값으로 데이터를 조각화해야 함
각각의 데이터 크기를 MTU에서 IPv4 프로토콜의 기본 크기인 20을 뺀 1480으로 설정하면 4000=1480+1480+1040, 총 3개로 나눌 수 있음
따라서 3개의 데이터로 조각화할 수 있으며, 마지막 패킷의 데이터 크기는 1040

10. ping 테스트를 통해 받은 응답 패킷으로 IPv4 프로토콜 확인 시 TTL이 119 -> 목적지 컴퓨터의 운영체제를 예상해 보면? 
윈도우
*윈도우의 TTL 값은 기본 128, 인터넷 상에서는 최대 16개 네트워크를 거쳐 목적지까지 도달하므로 예상되는 최대 TTL은 119+16 = 135
해당 값이 윈도우의 기본 TTL인 128보다 크므로, 목적지 컴퓨터의 운영체제는 윈도우로 예상 가능

 

7장. OSI 4계층

- 개인적으로 정보처리기사 필기 시험 준비하면서 가장 많이 들어본 부분이 아닐까 싶다. 그렇게 TCP와 UDP가 중요하다고 책이나 강의에서는 들었는데 정작 이 둘이 구체적으로 뭔지, 왜 중요한지 잘 모르고 있었다.

책을 읽고 실습을 해 보니 정말로 OSI 4계층은 TCP와 UDP가 거의 전부일 정도로 그 비중이 상당했다. 그 외에 체크섬, 데이터 송수신 등 시험 공부할 때는 아무것도 모르고 일단 딥다 외웠던 용어와 개념들을 조금이나마 직접 체득해본 유익한 시간이었다.

- 특히 TCP 프로토콜로 데이터를 주고받는 과정이 굉장히 복잡하다!! 어떤 내용이 있는지 대략은 파악했지만 과정을 모두 이해하기 마냥 쉽지 않았다. 7장은 일단 '퀘스트를 깨듯' 많은 실습 과정을 하나하나 해 보고 무사히 네트워크를 분석해내는 데 초점을 맞춰 공부한 듯하다.

7장 실습 1. 4계층 프로토콜 중 UDP 그 중에서 TFTP(단순 파일 전송 프로토콜)을 활용해 직접 서버와 클라이언트 간 통신 과정을 확인해 봤다. tftpd32라는 프로그램으로 내 컴퓨터에 가상 서버를 구축하고 파일을 클라이언트로 전송하는 과정이었다. UDP는 TCP에 비해 비교적 과정이 단순한 편이어서 직관적이었고, 어쨌든 미리 준비해둔 테스트 파일이 클라이언트(내 컴퓨터)에 정상적으로 전송된 모습이 신기했다!

 

7장 실습 2. 이번엔 TCP 프로토콜을 활용한 실습이다. 사진은 명령 프롬프트에서 netstat -ano 명령어로, 실행 중인 프로그램과 해당 프로그램이 사용 중인 포트 번호를 확인하는 모습이다. 흔히 사용하는 네이버 웹 사이트를 웹 브라우저로 열어본 뒤 명령어를 실행한 결과 중 일부인데, 블록 친 부분을 해석해보면 다음과 같다. "TCP를 사용해 192.168.0.101 IP 주소인 내 컴퓨터에서 프로그램 아이디(PID)가 20040인 프로그램(네이버를 열어본 웹 브라우저)이 포트 번호 49379를 사용 중. 그리고 151.101.129.44 IP 주소를 가진 컴퓨터(아마 네이버 웹 서버려나)에서 실행 중인 프로그램이 포트 번호 443을 사용 중이고 양쪽 포트는 ESTABLISHD 상태(클라이언트와 서버 양쪽 프로그램이 연결 수립되어 '데이터를 주고받을 준비가 되어 있는' 상태 )로 서로 연결되어 있음." TCP는 UDP에 비해 복잡한 데이터 주고받기 과정을 거치기에, 그 과정을 이해하고 실습하기도 다소 빡센 편이었다.

 

 

(7장 되새김 문제 풀이)

- 그렇게나 많은 분량을 자랑한 7장임에도 정작 되새김 문제에서 다뤄진 핵심 개념은 그리 많지 않아보인다.

1. 다음 각 설명이 나타내는 프로그램
- 서비스를 제공하는 프로그램: 서버
- 서비스를 이용하는 프로그램: 클라이언트

2. 대표적인 4계층 프로토콜로, 데이터를 안전하게 주고받기 위해 클라이언트와 서버가 지속적으로 통신하는 프로토콜 -> TCP
cf) UDP: 단순 파일 전송에 초점이 맞춰져 데이터 통신의 안전이 보장되지 않는 프로토콜

3. 클라이언트가 서버에 연결을 요청하기 위해 TCP 프로토콜을 캡슐화해 패킷을 보낼 때, 가장 먼저 보내는 패킷의 TCP에 설정하는 플래그 -> SYN 플래그

* SYN 플래그: TCP 연결 설정 초기화를 위해 순서 번호 동기화를 시작했음을 알리는 플래그

4. 클라이언트와 서버가 맨 처음 데이터를 주고받기 위해 서로 연결을 수립하는 과정 -> 3방향 핸드쉐이크

* 클라이언트와 서버가 마치 악수하듯 서로 패킷을 주고받는 과정을 총 3번 반복하는 것

-> 3-way(총 3번; 세 방향으로) handshake(악수하듯 데이터를 주고 받으며 연결을 수립)

5. 4계층에서 사용하는 주소 -> 포트 번호

* 포트 번호: 2계층의 MAC, 3계층의 IP처럼 4계층에서 사용하는 주소 역할을 하는 번호 -> 목적지 컴퓨터에서 실행 중인 여러 프로그램 중 데이터를 필요로 하는 특정 프로그램을 찾아가기 위한 번호

6. 다음 빈칸 채우기
- 연결이 수립된 두 프로그램이 ( 순서 ) 번호와 ( 응답 ) 번호로 서로 연결을 동기화 하며 통신

* 서로 연결 수립을 완료한 클라이언트와 서버는 서로의 통신을 동기화하며 순서 번호와 응답 번호를 주고 받음
순서 번호: TCP 연결 수립 과정에서 데이터 순서를 식별하는 번호
응답 번호: 데이터 수신 측이 보내는 '데이터 잘 받았다'는 신호 -> 순서 번호 + 1

7. 서버가 클라이언트 연결을 기다리고 있는 상태 -> LISTENING 상태

* 클라이언트의 요청을 '귀 기울여 듣고 있는' 상태

8. 클라이언트와 서버가 잘 연결된 상태 -> ESTABLISHED 상태

9. 프로그램끼리 연결된 상태 확인 명령어 -> netstat -ano

* 위 7장 실습 2에도 정리해 둠

10. 서버와 클라이언트 중 항상 연결을 요청하는 쪽 -> 클라이언트

 

8장. HTTP 통신 요청

- 8장부터는 본격적으로 웹 서비스와 관련된 네트워크 지식이 등장하는 걸로 보인다.

웹에 대해서는 최근 관심있게 찍먹해 본 경험이 있다(아직 제대로 된 웹 페이지를 만들어보진 않았지만 기본적인 웹 프로그래밍 책을 읽거나 구글링을 하며 기본 개념과 흐름을 공부해 본 정도). 일본 취업 교육과정에서도 주로 웹 개발에 대해 다루다 보니, 일본 취업이라는 목표를 위해서도 웹 개발에 더욱 관심을 가지게 되었다.

- 8장에는 기본적인 HTTP 프로토콜에 더해 프런트엔드와 백엔드, GET과 POST, URL 주소 등 웹 개발에 관심을 가진다면 한 번쯤 들어볼 수 있는 친숙한 용어들이 등장해 흥미롭게 공부했다. 실제 웹 개발 교육과정을 수강하며 취업 준비를 할 때도 실질적으로 도움이 될 만한 지식들로 구성되어 다른 장에 비해 좀 더 몰입이 잘 된 것 같기도 하다.

- 다만 아직 실습을 해 보지는 못했다. 실습에 사용할 프로그램을 다운로드 받아야 할 사이트가 계속 먹통인 상황이라 일단 보류 중이다(추후 사이트에 정상적으로 접속되면 다시 시도해 볼 예정)

-> (260309 추가) 사이트 정상적으로 접속됨, 설치 파일 다운로드에도 문제가 없어 실습을 해볼 수 있었다!

8장 실습. 위 세 줄은 ncat 프로그램을 활용해 네이버 웹 서버로 직접 보낸 HTTP 요청 프로토콜이다. 나머지 부분은 그에 대한 네이버 웹 서버의 응답 프로토콜로 보인다. 기본적인 요청 프로토콜 형식만 알아도 사용자가 직접 웹 서버에 HTTP 요청을 보낼 수 있음을 확인했다.

 

(8장 되새김 문제 풀이)
1. 7계층 대표 프로토콜, 웹 서버와 웹 브라우저가 데이터 주고받을 때 사용 -> HTTP

2. 웹 브라우저(클라이언트)가 웹 서버에 특정 데이터를 요청하는 과정에서, 요청에 필요한 정보(데이터)를 URL에 포함해 보내는 HTTP 메서드 -> GET 메서드

* GET 메서드 사용 시 전송 데이터가 URL 주소에 그대로 노출되므로 중요한 정보 전송에는 적합하지 않음
* POST 메서드: 요청에 필요힌 데이터를 요청 프로토콜의 보디 부분에 포함해, URL 주소 등 외부에 노출되지 않도록 함(아래 3번 문제 참고)

3. 2과 같은 과정에서, 요청에 필요한 데이터를 HTTP 보디에 포함해 (외부에 노출되지 않도록 함) 보내는 HTTP 메서드 -> POST 메서드

4. 웹 브라우저에 표시되는 웹 페이지 중 화면에 표시되는 실제 내용에 해당하는 문서 파일 -> HTML 파일

5. 웹 페이지 중 표시 내용의 디자인을 정의하는 파일 -> CSS 파일

6. 웹 페이지 중 특정 기능 실행을 담당하는 스크립트 코드 파일 -> 자바스크립트

* HTML: 웹 페이지의 틀, 구조(화면에 표시되는 실제 내용)
CSS: 웹 페이지의 디자인(HTML 파일을 더 예쁘게 꾸며줌)
자바스크립트: 웹 페이지의 세부 기능(-> 웹 페이지에 구체적으로 일 시키기)

7. 프런트엔드는 클라이언트 컴퓨터에서 실행, 백엔드는 (웹) 서버 컴퓨터에서 실행
* 프런트엔드 코드: HTML, CSS, 자바스크립트 등으로 작성된 내용
-> 서버로부터 내용을 다운로드 받아 클라이언트 파일에서 실행(사용자에게 직접 보이는 내용)
클라이언트 컴퓨터에서 실행 결과를 확인하고 해당 코드를 변경할 수 있음
백엔드 코드: 자바, PHP, 파이썬 등으로 작성된 내용
-> 클라이언트 요청을 받아 서버에서 실행한 뒤 그 결과만 클라이언트에게 전달
클라이언트 컴퓨터에서 코드를 확인하기 어려움(사용자에게 파일 내용이 직접 보이지 않음)

8. 서버 프로그램 실행 중인 컴퓨터의 특정 파일 저장 위치를 찾아가기 위한 주소 -> URL 주소(*locator: 특정 위치)

9. 클라이언트가 파일을 다운로드 받을 때 서버가 지정한 식별자를 이용하도록 하는 주소 -> URI 주소(*identifier: 식별자)

10. 클라이언트에서 서버로 POST 메서드를 이용해 데이터를 HTTP 프로토콜의 보디에 포함할 때, 사진이나 파일 업로드 등 데이터 전송 시 사용하는 콘텐트 형식 -> multipart/form-data
* application/x-www-form-urlencoded: 기본 문자 형태의 데이터 전송 시 사용, 키-값(key-value) 쌍
application/json: 자바스크립트 기반 JSON 형식 데이터 전송 시

* 참고 자료: JSON이란? https://www.json.org/json-ko.html (JSON 개요, 260306 최종접속)

-> 이전 Do it 자바 기초 언어 스터디 기록을 다시 꺼내보았다. 아마 컬렉션 프레임워크 부분에서 나왔던 걸로 기억한다. Map 인터페이스가 JSON과 비슷한 속성-값 쌍 구조였나?

(헷갈리면 다시 확인해보자)

https://gyeonkangkim.tistory.com/25

(Do it! 자바, 4주차) JDK 기본 클래스와 컬렉션 프레임워크 (260126~260130)

 

한 주를 마치며

- 1주차가 누구나 즐길 수 있는 달콤한 맛으로 시작해 극상의 매운맛으로 끝났다면, 2주차는 처음부터 강력한 매운맛을 선사하면서도 후반에는 매운맛 먹느라 고생했다며 적당히 쿨피스도 준 느낌이었다(특히 6장 문제풀이와 7장 TCP 프로토콜 부분이 많이 매웠다). 아무래도 말미에 웹 서비스 같이 비교적 친숙하면서 관심있던 개념이 등장해서가 아닐까 싶다. 웹 분야는 내 목표인 일본 IT 업계 취업에도 적지 않게 관련이 있다 보니 더 흥미있게 공부할 수 있었다.

역시 사람은 자신의 목표와 관련된 지식을 배울 때 더욱 힘이 솟는 존재인가보다.

 

- 네트워크는 역시 프로그래밍 언어에 비해 좀 더 친숙하게 다가온다. 아무리 AI나 바이브 코딩 시대가 도래한다고 한들 누구나 자바나 C 언어로 프로그램을 짤 수 있는 건 아니지만, 최소한 집에 와이파이 공유기는 하나씩 두고 쓰지 않는가. 즉 네트워크는 컴퓨터를 잘 모르는 사람도 일상에서 자주 접할 수 있는 분야인 것이다. 그래서일까.

개념이나 용어가 다소 어렵긴 해도 일상 속 문제를 퀘스트 깨듯 해결한다고 생각하니 나름 재미있게 공부할 수 있는 것 같다.

 

사용한 학습 자료

https://product.kyobobook.co.kr/detail/S000213766983

Do it! IT 서비스 이해를 위한 네트워크 기초 | 심준보 - 교보문고

(밀리의 서재에서 이용 중)