Dratini의 공부공방

서브넷 마스크?

서브넷 마스크는 32비트의 숫자로 구성된다. 이 숫자들은 '0'과 '1'로 이루어져 있다.

여기서 '0'의 비트는 호스트 부분을 나타내고, '1'의 비트는 네트워크 부분을 나타내는데, 이를 통해서 서브넷 마스크는 IP 주소를 네트워크 주소와 호스트 주소로 분리시켜준다.

이렇게 IP 주소를 '마스킹'하는 것이기 때문에 '서브넷 마스크' 라고 부른다.

그래서 서브넷이 뭔데?

전 세계에는 수백만 개의 네트워크가 존재하며, 그 규모는 너무나 다양하다.

큰 규모의 네트워크는 관리하기 어렵기 때문에, 이를 작은 조각으로 나누어 관리하는 것이 효율적이다.
그렇게 나뉜 작은 네트워크를 '서브넷' 이라고 한다. 그리고 이러한 과정을 '서브네팅' 이라고 하며, 이를 통해 네트워크 성능을 개선하고 자원을 효율적으로 분배할 수 있다.

서브네팅은 관리의 용이성, 고급 네트워크 보안, 네트워크 트래픽 감소 등 여러 장점을 가지고 있다. 또한, 서브네팅을 통해 인터넷 서비스 업체로부터 추가적인 IP 주소를 받을 필요가 없다. 하지만, 서브네팅을 위해 추가적인 하드웨어가 필요한 경우가 있어, 이로 인한 비용이 발생할 수 있다는 단점도 있다.

서브넷 마스크의 작동 원리

IP 주소는 네트워크 구성요소와 호스트 구성요소로 이뤄져있다. 예를 들어, '192.168.123.132'라는 IP 주소에서 '192.168.123.'는 네트워크를 나타내고, '132'는 네트워크에 연결된 기기를 가리킨다.

IP 주소는 32비트로 구성되고, 이를 십진수 체계로 표현하면 다음과 같다

: '192.168.123.132' = '11000000.10101000.01111011.10000100'.

이 IP 주소의 서브넷 마스크는 네트워크 부분을 반영하며, 다음과 같이 나타낼 수 있다

: '255.255.255.0' = '11111111.11111111.11111111.00000000'.

이 둘을 합치면 다음과 같은 결과를 볼 수 있다

'11000000.10101000.01111011.00000000' (네트워크 주소: '192.168.123.0')
'00000000.00000000.00000000.10000100' (호스트 주소: '000.000.000.132')

여기서 '192.168.123.0'이 서브넷이며, '192.168.123.132'는 대상 주소(서브넷 내 기기)다.

IP 주소 클래스

IP 주소 클래스는 A, B, C로 나뉩니다. 각 클래스마다 기본 서브넷 마스크가 다르며, IP 주소의 첫 세 자리를 확인하여 클래스를 확인할 수 있다.

• 클래스 A: 255.0.0.0의 서브넷 마스크를 이용하며 첫 옥텟(8비트로 구성된 부분)은 0~127로 구성되어 있습니다. 126개의 네트워크를 허용하며 네트워크당 호스트가 거의 1,700만 개에 달한다.
• 클래스 B: 255.255.0.0의 서브넷 마스크를 이용하며 첫 옥텟은 128~191로 구성된다. 클래스 B IP 주소는 중간 규모와 대규모 네트워크에서 이용한다. 클래스 B는 약 1600개의 네트워크를 허용하며 네트워크당 65,000개의 호스트를 허용한다.
• 클래스 C: LAN(Local Area Network)에 이용되며 200만 개의 네트워크를 허용하고 각각 254개의 호스트를 두고 있다. 클래스 C는 255.255.255.0의 서브넷 마스크를 이용하고 첫 옥텟은 192~223으로 구성되어 있다.

서브넷 마스크를 찾는 방법

 서브넷 마스크를 찾는 방법은 운영 체제에 따라 다르다.
 아래는 MacOS, Windows, iOS, Android 운영체제에서 서브넷 마스크를 찾는 방법이다.

• MacOS: 시스템 환경설정 > 네트워크로 이동하세요. 네트워크를 선택하시고 고급을 클릭하세요. TCP/IP 탭을 클릭하시면 서브넷 마스크와 함께 IP 주소를 확인할 수 있습니다.
• Windows: 제어판 > 네트워크 및 인터넷으로 이동하세요. 네트워크 이름을 선택한 후 세부사항을 클릭합니다. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.
• iOS: 설정 > Wi-Fi로 이동하세요. 현재 연결된 네트워크를 확인하시고 ‘i’ 아이콘을 클릭하세요. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.
• Android: 설정 > 연결 > Wi-Fi로 이동하세요. 현재 연결된 네트워크를 탭하세요. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.

소켓

 소켓은 네트워크에서 두 대의 디바이스 간의 데이터 송수신을 위한 통신 엔드포인트(도착점, 시작점)이라고 할 수 있다.

 즉, 소켓은 클라이언트-서버 모델에서 클라이언트와 서버 사이에 데이터를 전송할 수 있는 통신 경로를 제공해주는 일종의 톨게이트같은 역할을 한다.

 보통 인터넷 프로토콜(IP), 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP)을 사용하여 소켓 통신을 사용한다.

 한가지 예시를 들어보자.

 이메일을 전송할 때, 송신자의 컴퓨터와 수신자의 메일 서버 사이에는 소켓이 만들어져 이메일 데이터가 전달된다. 소켓을 통해 두 기기는 안전하고 효율적으로 통신을 할 수 있다.

포트

포트는 네트워크에서 특정 소프트웨어에 데이터를 전달하기 위한 통신 채널을 식별하는 번호다. 포트 번호는 0부터 65535까지의 범위를 가지며, 일반적으로 잘 알려진 포트 번호와 동적 포트 번호로 나뉜다.

예를 들어, HTTP 통신은 기본적으로 80번 포트를 사용하며, HTTPS 통신은 443번 포트를 사용한다.

 즉, ip주소가 우리나라의 도로명 주소라면, 포트번호는 아파트의 동 호수라고 볼 수 있다.

소켓과 포트, 둘의 차이점

 소켓은 데이터 통신을 위한 통신 엔드포인트로, 컴퓨터와 서버 간의 연결을 가능하게 하는 기능을 한다.

 그러나 포트는 특정 프로세스나 서비스에 데이터를 전달하기 위한 통신 채널을 식별하는 번호다.

 소켓은 통신 경로를 제공하고 관리하는 역할을 하며, 포트는 통신 과정에서 데이터가 어떤 프로세스나 서비스에 도달해야 하는지를 구분한다.

 즉, 소켓이 아파트 입구의 도로라고 한다면, 포트는 아파트의 동호수라고 할 수 있다.

참고 : https://www.geeksforgeeks.org/difference-between-socket-and-port/

https://www.ibm.com/docs/ko/ssw_ibm_i_73/rzab6/rzab6soxoverview.htm

HTTP 응답 코드는 HTTP 요청에 대한 서버의 응답을 나타내는 3자리 숫자를 말한다.

이 숫자는 해당 요청이 성공했는지, 실패했는지, 그리고 어떤 종류의 오류가 발생했는지를 나타낸다.

응답코드는 크게 5개 분류로 나뉘는데 100, 200, 300, 400, 500번대이다.

상태코드의 분류별 특징

• 100번대 (처리 중) : 이 코드는 요청이 수신되었으며 처리가 계속되고 있다는 것을 말해준다. 일반적으로 클라이언트의 추가 작업이 필요하다. 예를 들어 101 Switching Protocols는 서버와 클라이언트 간의 프로토콜을 변경했다는 뜻이다.

• 200번대 (성공): 200번대 응답 코드는 성공적으로 처리되었음을 나타낸다. 예를 들어, 200 OK는 요청이 성공적으로 처리되었다는 것을 나타내며, 201 Created는 새로운 리소스가 성공적으로 생성되었다는 것을 나타낸다.

• 300번대 (리다이렉션): 300번대 응답 코드는 리다이렉션을 말한다. 즉, 요청한 리소스가 다른 위치에 있고, 새로운 위치로 이동하도록하는 요청이다. 예를 들어, 301 Moved Permanently는 요청한 리소스가 영구적으로 새로운 URL로 이동되었다는 것을 나타내며, 302 Found는 요청한 리소스가 일시적으로 새로운 URL로 이동되었다는 것을 말한다.

• 400번대 (클라이언트 오류): 400번대 응답 코드는 클라이언트 오류를 나타낸다. 즉, 클라이언트가 요청한 것이 잘못되었거나 부적절한 경우에 볼 수 있다. 예를 들어, 400 Bad Request는 클라이언트가 유효하지 않은 요청을 보냈다는 것을 나타내며, 401 Unauthorized는 클라이언트가 인증되지 않았다는 것을 나타낸다.

• 500번대 (서버 오류): 500번대 응답 코드는 서버 오류를 말해준다. 즉, 서버에서 요청을 처리하는 동안 문제가 발생한 경우다. 예를 들어, 500 Internal Server Error는 서버에서 오류가 발생했다는 것을 나타내며, 503 Service Unavailable은 서버가 일시적으로 사용 불가능하다는 것을 말해준다.

각 응답 코드는 위처럼 분류된다.

세부 상태코드 의미

1xx - Informational (정보)

2xx - Successful (성공)

3xx - Redirection (리디렉션)

4xx - Client Error (클라이언트 오류)

5xx - Server Error (서버 오류)

 HTTP 응답 코드는 클라이언트와 서버 간의 통신에서 중요한 역할을 한다. 그래서 이러한 응답 코드의 세부 내용을 이해하고 적절히 대응하는 것이 중요하다.

 물론 이 외에도 많은 상태코드들이 있다. 이외의 상태코드에 대해서는 아래 링크를 통해 확인하면 좋을 것 같다.

참고 : https://developer.mozilla.org/ko/docs/Web/HTTP/Status

HTTP 프로토콜

 HTTP(Hypertext Transfer Protocol)는 인터넷에서 데이터를 주고받는 데 사용되는 프로토콜 중 하나이다. HTTP는 웹 브라우저와 웹 서버 간의 통신을 위해 개발되었으며, HTML, CSS, Javascript 등의 문서를 전송하기 위한 표준 프로토콜로 사용된다.

 HTTP는 클라이언트-서버 모델을 따르며, 클라이언트(보통은 웹 브라우저)가 서버에 요청(Request)을 보내고, 서버는 클라이언트에게 응답(Response)을 보낸다. 이때, 요청과 응답은 HTTP 메시지라는 형식으로 전송된다.

 HTTP는 기본적으로 평문(Plain text)으로 데이터를 전송하기 때문에  데이터의 기밀성과 보안에 취약점이 존재한다. 따라서, 이 문제점을 보완하기 위해서 HTTP보다 보안성이 높은 HTTPS가 등장했다.

HTTPS 프로토콜

 HTTPS(Hypertext Transfer Protocol Secure)는 HTTP 프로토콜의 보안 강화 버전입니다. HTTPS는 HTTP와 마찬가지로 인터넷 상에서 데이터를 주고받는 데 사용되며, SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화하고 보호해준다.

 HTTPS는 HTTP와 달리, 클라이언트와 서버 간에 암호화된 통신 채널을 사용합니다. 이 암호화된 통신 채널을 통해 데이터가 전송되기 때문에, 중간자 공격(네트워크 통신을 조작하는 보안 공격)과 같은 보안 위협으로부터 보호받을 수 있다.

 HTTPS의 동작 방식은 이렇다.
.

1. 클라이언트는 서버에 접속하고, SSL/TLS 암호화 방식을 사용하여 인증 요청을 보낸다.
2. 서버는 인증서를 클라이언트에게 보내고, 클라이언트는 이 인증서가 신뢰할 수 있는지 확인한다.
3. 클라이언트와 서버 간에 공유된 비밀키를 사용하여 데이터를 암호화하고 전송한다.

참고 : https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

https://www.ibm.com/docs/ko/aix/7.1?topic=systems-client-server 

Chrome이나 Safari같은 웹브라우저의 검색창에 http://google.com 을 검색하면 브라우저는 입력된 URL의 프로토콜(http)을 파싱해서 어떤 프로토콜인지 확인하고, "http" 프로토콜을 사용하여 "google.com" 도메인에 대한 HTTP 요청을 생성한다.

그렇다면 이 과정은 어떻게 될까?

   1. 로컬 DNS 캐시에서 검색

 먼저 브라우저는 로컬 DNS 캐시에서 "google.com" 도메인 이름과 관련된 IP 주소를 찾는다.
 로컬 DNS 캐시는 이전에 방문한 도메인 이름의 IP 주소를 저장한다. 만약 캐시에 해당 도메인 이름의 IP 주소가 있으면, 브라우저는 바로 해당 IP 주소로 HTTP 요청을 보낸다.

   2. 로컬 DNS 서버에서 검색

 만약 로컬 DNS 캐시에 해당 도메인 이름의 IP 주소가 없으면, 브라우저는 로컬 컴퓨터에 설정된 기본 DNS 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다.
 로컬 DNS 서버는 이를 받아들이고, 자신이 가지고 있는 DNS 캐시에서 "google.com" 도메인 이름과 관련된 IP 주소를 찾는다.

   3. 로컬 DNS 서버에서 검색

 만약 로컬 DNS 서버에도 해당 도메인 이름의 IP 주소가 없으면, 로컬 DNS 서버는 인터넷에서 가장 높은 계층에 위치한 루트 DNS 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다.
 루트 DNS 서버는 이를 받아들이고, "com" 도메인 이름을 관리하는 TLD(Top-Level Domain) DNS 서버의 IP 주소를 알려준다.

   4. TLD DNS 서버에서 검색

 로컬 DNS 서버는 TLD DNS 서버의 IP 주소를 받은 후, 해당 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다.
 TLD DNS 서버는 이를 받아들이고, "google.com" 도메인 이름을 관리하는 DNS 서버의 IP 주소를 알려준다.

   5. 도메인 이름을 관리하는 DNS 서버에서 검색

로컬 DNS 서버는 마지막으로 "google.com" 도메인 이름을 관리하는 DNS 서버에게 "google.com" 도메인 이름과 관련된 IP 주소를 질의한다. 이 DNS 서버는 "google.com" 도메인 이름에 대한 IP 주소를 알려준다.

   6. 로컬 DNS 서버에 도메인 저장

로컬 DNS 서버는 해당 정보를 자신의 DNS 캐시에 저장하고, 해당 정보를 웹 브라우저에게 반환한다. 웹브라우저는 반환받은 IP주소를 바탕으로 해당 도메인의 웹 페이지를 불러온다.

 이런 기나긴 여정을 통해서 google.com의 웹 페이지가 사용자의 화면에 보일 수 있는 것이다.
 물론 "6. 로컬 DNS 서버에 도메인 저장"  에서 유추할 수 있듯이 이미 한번 질의과정을 거쳐 로컬 DNS 서버의 캐시에 도메인이 저장된 경우에는 위와 같은 질의 과정이 필요없다.

참고 : https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/