지난해 너무 놀고먹고 한 죄를 청산하고자
의지를 체면과 돈으로 사서 겨우겨우 공부하고 있는데요
(참여 예고까지 한 혼공단 완주는 내 블로그 체면이 되)
2-3월에 할 일 디지게 많아요^ㅁ^
너무 무리했나바요...
차근차근 정리+계획해 보려다가 때려치우고 걍 일단 하자!! 마인드로 가봅니다
우선 혼공네트 책을 도서관에 가져다 드려야 할 날이 임박하여
일정표와 달리 예습하는 콘텐츠로 준비했어요
벌써 5주 차인 오늘 할 공부는요
<목차>
Chapter 1. 컴퓨터 네트워크 시작하기
Chapter 2. 물리 계층과 데이터 링크 계층
Chapter 3. 네트워크 계층
Chapter 4. 전송 계층
Chapter 5. 응용 계층
Chapter 6. 실습으로 복습하는 네트워크
Chapter 7. 네트워크 심화
네트워크 모델의 최상단 응용 계층이라죠
OSI 7 모델 기준으로는 응용/표현/세션 계층이었는데요
이 구조 기억하는 새럼~?!
혼공단 숙제는요 HTTP 요청 메시지 확인해 보는 거라죠
지난 내용 복습하기
빠지면 서운한 복습부터 가보겠습니다
포스팅한 지 이틀 밖에 안 지났는데 벌써 기억 안나고요 ㅎ
| 계층명 | 지난 주 핵심 | 다 합쳐서 복습하기 |
| 전송 | 연결/신뢰형 통신 프로토콜 TCP (연결 수립 및 종료 방식인 핸드셰이크 +오류/흐름/혼잡 제어) 비연결/비신뢰형 통신 프로토콜 UDP (속도 빠른 실시간성 서비스) |
- 연결형 통신, 신뢰성 있고 안전성 있는 통신을 해야 할 때 필요한 계층 - OSI 7계층 중 하위 3계층과 상위 3계층간 인터페이스 담당 - 재전송을 통한 오류 제어, 흐름 제어 혼잡 제어 수행 - 전송 단위는 세그먼트 - 장비는 게이트웨이 - 관련 프로토콜로는 TCP, UDP (포트) 특정 애플리케이션까지 패킷을 전달하기 위해 사용하는 식별정보 - 16비트(2바이트)로 표현하며, 번호 범위에 따라 잘 알려진 포트(0~1023), 등록된 포트(1024~49151), 동적 포트(49152~65535)로 구분함 - 전송 계층에서는 패킷 내 송/수신지 포트 번호를 통해 송/수신지 호스트의 애플리케이션을 식별함 - NAPT는 포트를 활용해 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있도록 하여, 공인 IP 주소 수 부족 문제를 개선하는 NAT 기술 (TCP) 신뢰성, 연결지향적, TCP 상태 사용. 오류/흐름/혼잡 제어 - 가상회선 방식으로, 패킷 전송 순서를 보장하고 수신 여부도 확인함 >> TCP 연결 수립은 3 웨이 핸드셰이크, 연결 종료는 4 웨이 핸드셰이크를 사용함 - 데이터 신뢰성이 높은 대신 속도가 느림 - (오류 제어) 데이터 오류/유실 발생시 재전송을 통해 신뢰성을 보장하려는 방식 중복된 ACK 수신 혹은 타임아웃 발생시 재전송을 하는데, Stop-and-Wait, Go-Back-N, Selective Repeat ARQ가 가장 대표적인 방식 - (흐름 제어) 데이터 송수신측간 데이터 처리 속도 차이로 인한 데이터 손실을 방지하려는 방식으로, 수신측이 주체. 파이프라이닝과 슬라이딩 윈도우 활용 - (혼잡 제어) 데이터 송신 측의 전달 속도와 네트워크의 속도 차이로 인한 데이터 손실을 방지하려는 목적. 송신 측이 주체. 혼잡 윈도우를 통해 네트워크 혼잡도를 판단, 혼잡한 정도에 따라 전송량을 유동적으로 조절하는 방식 대표적인 혼잡 제어 알고리즘으로 AIMD, 느린 시작, 혼잡 회피, 빠른 회복 등이 있으며, 네트워크 상황에 따라 각 방식을 함께 이어서 사용 (UDP) 비신뢰성, 비연결성, 스테이트리스 프로토콜 - 데이터그램 패킷 교환 방식으로, 패킷 순서 보장이나 수신 여부 확인을 하지 않음 - 데이터 신뢰성이 낮은 대신 속도가 빨라 실시간 서비스에 적합 |
| 네트워크 | 인터넷 프로토콜 IP IP 주소(IPv4, IPv6) ARP(IP to MAC) 네트워크 클래스 NAT(공인/사설IP) DHCP(IP 동적할당) 라우팅 프로토콜 (내부 RIP&OSPF, 외부 BGP) |
- 메시지를 다른 네트워크에 속한 수신지까지 전달하는 계층 = 네트워크 간 통신 계층 - IP는 데이터그램 기반 비신뢰성, 비연결성 서비스로, IP 단편화(패킷의 분해 및 조립), IP 주소 지정, 경로 선택 기능을 가짐 - 개방 시스템 들 간 네트워크 연결 설정/유지/관리 기능, 데이터의 교환/중계 기능, 경로 제어, 패킷 교환, 트래픽 제어 등의 기능을 수행함 - 전송 단위는 패킷 - 장비로는 라우터 - 관련 프로토콜로는 IP, ICMP, IGMP, ARP, RARP 등 - IPv4는 4바이트(32비트)+10진수 표현, 클래스 단위로 비순차적으로 할당함. 보안 기능이 없으며, 패킷 크기에 제한(64바이트)이 있음. 유니캐스트/브로드캐스트/멀티캐스트 방식을 사용함 - IPv6는 16바이트(128비트)+16진수 표현, 네트워크/단말 순서로 순차적으로 할당함. 확장 헤더를 사용해 인증/보안 기능을 포함하며, 패킷 크기에 제한이 없음. 유니캐스트/멀티캐스트/애니캐스트 방식을 사용함 - 하나의 IP 주소는 네트워크 주소와 호스트 주소로 구성된 - (클래스 풀 주소 체계) 네트워크 크기에 따라 IP 주소를 분류하는 걸 클래스라 함. 클래스는 A~E까지 5개 존재. 클래스 풀 주소는 네트워크 크기가 고정이라는 한계가 존재함 - (클래스리스 주소 체계) 네트워크 주소는 1로, 호스트 주소는 0으로 표기하여 임의로 나누는 방식을 서브넷 마스크라 함. IP 주소와 서브넷 마스크를 비트 AND 연산하면 네트워크 주소가 나온다. 서브넷 마스크는 10진수로 표기하거나, IP 주소/서브넷 마스크 상 1의 개수 형식으로 표현하는 CIDR 표기법을 사용함 - ARP 프로토콜은 "동일 네트워크 내에서" IP 주소를 통해 MAC 주소를 알아내는 과정. ARP 요청(브로드캐스트) > ARP 응답(유니캐스트) > ARP 테이블 갱신 순으로 동작한다. - NAT는 공인 IP와 사설 IP를 상호 변환해주는 기술 - DHCP는 네트워크 안의 호스트들에게 IP와 DNS 서버, 서브넷 마스크 주소를 동적으로 할당하는 프로토콜. DHCP 할당은 DISCOVER, OFFER, REQUEST, ACK 4단계로 구성됨(모두 브로드캐스트). - 라우팅 프로토콜은 라우터끼리 자신들의 정보를 교환하며 패킷이 이동할 최적의 경로를 찾고자 사용. AS 내부에서 수행되면 IGP로 RIP와 OSPF가 있고, 외부에서 수행되면 EGP로 BGP가 있음 - IGP는 거리 벡터를 사용하는 RIP와 링크 상태를 사용하는 OSPF/IS-IS로 나뉨 |
| 데이터 링크 | NIC 스위치 (전이중 통신+VLAN) |
- 네트워크 내 주변장치 간 정보를 올바르게 주고받기 위한 계층 - MAC 주소 체계를 통해 네트워크 내 송수신지를 특정 - 물리적으로 연결된 인접한 개방 시스템들 간 신뢰/효율적 정보 전송을 위해 시스템 간 연결 설정과 유지 및 종료 담당 - 오류 검출 및 회복을 위한 오류 제어, 송수신측 속도 차이 해결을 위한 흐름 제어, 프레임 순서적 전송을 위한 순서 제어 기능을 가짐 - 전송 단위인 프레임에 물리적 주소를 부여함 - 장비로는 랜카드, 브리지, 스위치 등 - 관련 프로토콜로는 HDLC, LAPB, LLC, MAC, LAPD, PPP, 이더넷 등 - 스위치는 전이중 통신을 한다. MAC 주소 학습과 테이블을 이용해, 특정 MAC 주소를 가진 호스트에만 프레임을 전달할 수 있다. MAC 주소 학습은 플러딩, 포워딩과 필터링, 에이징을 통해 이루어진다. - 스위치는 또한 가상의 LAN을 만드는 VLAN 기능을 지원한다. |
| 물리 | 트위스티드 페어 케이블 광섬유 케이블 허브(반이중 통신+CSMA/CD) |
- OSI 모델 최하단 계층 - 0과 1로 표현되는 비트 신호를 주고 받음 (전송단위가 Bit) - 통신 케이블로 데이터를 전송하는 물리적 장비에 필요한 기계/전기/기능/절차적 특성에 대한 규칙을 정의 - 장비로는 통신 케이블, 리피터, 허브 등 - 관련 프로토콜로는 RS-232C, X.21 등 - 허브는 반이중 통신을 해서 무전기처럼 송수신을 번갈아 가면서 한다. 다른 호스트가 기다리지 않고 신호를 보낼시 충돌 위험이 있는데 이를 방지하는 프로토콜이 CSMA/CD이다. Carrier Sense(캐리어를 감지하고) Multiple Access(다중 접근시에) Collision Detection(충돌을 검출)한다. |
그럼 본격적으로 5주 차 공부 시작해 볼게요
도메인 네임과 (도메인) 네임 서버
우리가 브라우저에 특정 URL을 입력하면 웹 페이지가 뜬다. 뒷단에서 클라이언트와 서버가 요청-응답 메시지를 송수신하고 있기 때문인데, 이때 서버와 클라이언트는 '메시지를 주고받고자 하는 대상'과 '주고받고자 하는 정보'를 알아야 한다.
앞서 공부하면서 '메시지를 주고 받고자 하는 대상'을 알기 위해서는 IP 주소를 사용한다고 배웠다. 하지만 숫자를 언제 다 외워요...? 요즘은 가족 휴대폰 번호도 가끔 헷갈리는 지경인데 말이죠^^ 그래서 우리는 IP 주소 대신 tistory.com과 같은 문자열을 활용해 웹 페이지에 접속하는데요. 이렇게 호스트 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보를 도메인 네임 Domain name이라고 한다.
도메인 네임과 IP 주소는 네임서버 Name server 에서 관리한다. DNS 서버라고도 부르는데, 인터넷 세계의 공용 전화번호부 같은 개념이라고 보면 된다. 아래 그림처럼, 도메인 네임을 네임 서버에 질의하면 해당 도메인 네임에 대한 IP 주소를 알려주는 방식으로 동작한다.
# 도메인 네임 구조
도메인 네임은 점(.)을 기준으로 계층적으로 분류한다. 최상단에 루트 도메인이 있고, 최상위 도메인, 2단계 도메인, 3단계 도메인 이렇게 순차적으로 내려가는 형태다. 이렇게 생겼는데,
- 루트 도메인 : 점(.)으로 표현되는, (실제) 도메인 네임의 마지막 부분. 일반적으로 생략하고 표기함
- 최상위 도메인(TLD) : 일반적으로 생각하는 도메인 네임의 마지막 부분. com, org, net과 같은 일반TLD와 kr, us, cn과 같은 국가코드TLD로 나뉨
- 2단계 도메인 : 최상위 도메인 하부 도메인으로, www.tistory.com에서 tistory에 해당하는 부분
- 3단계 도메인 : www.tistory.com에서 www에 해당하는 부분 (일반적으로 3~5단계 정도까지만 사용)
www.tistory.com와 같이 도메인 네임을 모두 포함하는 도메인 네임을 전체 주소 도메인 네임(FQDN)이라 한다. 분석해 보면 아래와 같은데,
| 3단계 | 2단계 | 최상위 | 루트 | ||
| www | . | tistory | . | com | . |
여기서 FQDN의 첫 번째 부분을 호스트 네임이라고 부르기도 한다. 뒷부분이 tistory.com으로 끝나는 수많은 도메인 주소 중에서, www.tistory.com이라는 호스트를 식별할 수 있는 하나밖에 없는 애이기 때문이다. 반대로 lv27.tistory.com, notice.tistory.com으로 끝나는 애들은, 다른 도메인이 포함된 도메인이라 서브 도메인 subdomain 이라 한다.
# 계층적 네임 서버
계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버 또한 계층적인 형태를 이룬다. 계층 서버는 전 세계에 널리 퍼져 있는데, 이렇게 분산된 도메인 네임에 대한 관리 체계를 도메인 네임 시스템, DNS라 부른다. DNS는 호스트가 도메인 네임 시스템을 이용할 수 있게 하는 애플리케이션 계층 프로토콜을 지칭하기도 한다. 우리가 IP 주소를 모르는 상태에서 도메인 네임에 대응하는 IP 주소를 알아내는 과정을 '도메인 네임을 풀이resolve한다' 또는 '리졸빙'이라고 표현한다. 이 과정에는 로컬 네임 서버, 루트 네임 서버, TLD 네임 서버, 책임 네임 서버와 같이 다양한 네임 서버들이 필요하다.
- 로컬 네임 서버 : 클라이언트와 맞닿아 있는 네임 서버로, 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버. 로컬 네임 서버의 주소는 보통 ISP에서 할당해 주지만, 필요하다면 공개 DNS 서버를 이용할 수도 있음(구글 공개 DNS 서버는 8.8.8.8과 8.8.4.4
- 루트 네임 서버 : 루트 도메인을 관장하는 네임 서버로, 로컬 네임 서버의 질의에 대해 TLD 네임 서버의 IP 주소를 반환함
- TLD 네임 서버 : TLD를 관리하는 네임 서버로, 질의에 대해 TLD 하위 도메인 네임을 관리하는 서버 주소를 반환함
- 책임 네임 서버 authoritative name server : 특정 도메인 영역zone을 관리하는 네임 서버로, 자신이 관리하는 도메인 영역의 질의에 대해서는 곧바로 대답이 가능함 = 로컬 네임 서버가 마지막으로 질의하는 네임 서버임
# 도메인 네임을 리졸빙하는 과정 = ⭐️ 재귀적 질의와 반복적 질의 ⭐️
| 재귀적 질의 recursive query | 반복적 질의 iterative query |
| 클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버가 루트 네임 서버에게 질의하고, 루트 네임 서버가 TLD 서버에게 질의하고, TLD 네임 서버가 다음 단계에 질의하는 과정을 반복해 최종 응답 결과를 역순으로 전달받는 방식 |
클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버는 루트 도메인 서버에게 질의해서 응답받고, 다시 로컬 네임 서버가 TLD 서버에게 질의해서 응답받고, 다시 로컬 네임 서버가 다음 서버에게 질의하는 과정을 반복해 최종 응답 결과를 클라이언트에게 알려주는 방식 |
| 로컬 네임 서버는 루트 네임 서버에게 1번만 물어봄 각 서버가 단계별로 내려가면서 물어보고, 자신이 받은 답변을 위로 올려줌 |
로컬 네임 서버가 루트~책임 서버까지 다 물어봄 |
 |
 |
근데 매번 이렇게 물어보면 시간도 오래 걸리고 네트워크에 부담이 많이 간다죠. 그래서 기존에 응답받은 결과를 저장해 두었다가, 나중에 같은 질의가 또 오면 대답해주기도 한다. 이를 DNS 캐시라고 하는데요, 저장된 값은 일정 시간(TTL)이 지나고 나면 폐기한다.
# DNS 레코드 타입
네임 서버는 DNS (자원) 레코드라 불리는 정보를 저장하고 관리한다. 도메인 네임을 구입한 뒤에, 웹 사이트에 도메인 네임을 적용시킬 때 사용하게 된다. 도메인 네임이 특정 IP에 대응된다는 사실을 네임 서버에게 알리기 위해 추가하는 작업을 해줘야 하는 것이다. 보통 가비아 같은 곳에서 설정할 수 있다. 아래처럼 생겼는데,
DNS 레코드에는 이름(호스트)과 값/위치, TTL, 타입이 있다.
각 레코드에는 유형이 정해져 있는데, 자주 접하는 ⭐️레코드 유형은 아래와 같다.
| 레코드 유형 | 설명 |
| A (host record) |
특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계 호스트 이름이 정의된 주 영역이라고 보기도 함 |
| AAAA | 특정 호스트에 대한 도메인 네임과 IPv6 주소와의 대응 관계 |
| CNAME | 호스트 네임에 대한 별칭 지정 |
| NS | 특정 호스트의 IP 주소를 찾을 수 있는 네임 서버 |
| MX | 해당 도메인과 연동되어 있는 메일 서버 |
짧게 정리하고 넘어가자면 DNS의 주요 기능은 네임 공간(구조) 생성, 네임 등록 관리, 네임을 IP로 변환 정도라고 보면 될 듯
시험에 자주 나오는 개념들은 이제 ⭐️을 달기로 했다
근데 가비아 홈페이지 보니까 또... 회사 생각나네
시스템 기획/운영 업무하면 도메인 사고 레코드 설정도 하고 그렇답니다^ㅁ^
# 자원을 식별하는 URl
이제까지 서버와 클라이언트가 알아야 하는 정보 중 '메시지를 주고받고자 하는 대상'과 관련된 개념을 공부했다. 그렇다면 '주고받고자 하는 정보'는 어떻게 알 수 있을까? 우선 이렇게 네트워크상에서 메시지를 통해 주고받고자 하는 정보를 자원이라고 부른다. 자원은 HTML 파일부터 이미지, 동영상, 텍스트 파일과 같이 정말 다양하다.
네트워크 상에서 자원을 주고받으려면 자원을 식별할 수 있어야 한다. 자원을 식별할 수 있는 정보를 URI, Uniform Resource Identifier라고 부른다. 이름 뜻 그대로 자원을 식별하는 통일된 방식이다. URI에는 위치를 이용해 자원을 식별하는 URL과, 이름을 이용해 자원을 식별하는 URN이 있다.
오늘날 더 많이 쓰이는 방법은 URL, Uniform Resource Locator이다. URL은 보통 이렇게 생겼다.
| foo | :// | www.example.com:8042 | /over/there | ?name=hongong | #hanbit |
| scheme | authority | path | query | fragment |
- scheme (자세한 종류는 여기서)
자원에 접근하는 방법을 의미하며, 일반적으로 사용할 프로토콜을 명시함
http를 사용하면 http://, https를 사용하면 https://
- authority
호스트를 특정할 수 있는 정보로 IP 주소나 도메인 네임을 기재함. 콜론(:) 뒤에 포트 번호 붙이기도 함
- path
자원이 위치한 경로
슬래시(/)를 기준으로 계층적으로 표현하며, 최상위 경로도 /로 표현
- query
복잡한 요구를 포함하는 HTTP 요청 메시지를 보낼 때 사용하며, 쿼리 문자열 또는 쿼리 파라미터라 함
물음표(?)로 시작되는 <키=값> 형태로, 앰퍼샌드(&) 연산자를 사용해 연결해서 쓴다 >>> ?key=value&key2=value2
쿼리 문자열은 서버 개발자가 설계하기 나름이라 매우 다양함
- fragment
자원의 한 조각을 가리키기 위한 정보 >> html 페이지 내 특정 부분을 가리키는 등
응용 계층 대표 프로토콜, HTTP
# HTTP의 특성 4가지
(1) 요청-응답 기반 프로토콜
HTTP는 클라이언트-서버 구조 기반의 요청-응답 프로토콜이다. HTTP는 클라이언트와 서버가 서로 HTTP 요청과 응답 메시지를 주고받는 구조로 동작한다.
(2) 미디어 독립적 프로토콜
HTTP는 클라이언트와 서버가 주고 받는 자원의 특성을 제한하지 않는다. 자원의 특성과 무관하게 그저 자원을 주고 받는 수단(인터페이스)의 역할만을 수행한다.
HTTP에서 메시지로 주고 받는 자원의 종류를 미디어 타입, 또는 MIME 타입(Multipurpose Internet Mail Extensions Type)이라 한다. 미디어 타입은 일종의 웹 세상의 확장자와 같은 개념으로, <타입/서브타입>으로 구성된다. text/html, image/png 같은 형태다.
(3) 스테이트리스 프로토콜
HTTP는 상태를 유지하지 않는 스테이트리스 프로토콜이다. 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미로, 클라이언트의 모든 HTTP 요청은 독립적 요청으로 간주된다.
HTTP 서버는 보통 여러 개가 있고, 많은 클라이언트들과 동시에 상호 작용한다. 이러한 상황에서 클라이언트의 상태 정보를 유지하고 서로 공유하는 일은 쉽지 않다. 그래서 오히려 독립적으로 간주하는 것이 더 효율적이다.
게다가 HTTP의 가장 중요한 설계 목표는 바로 확장성 scalability와 견고성 robustness 이다. 상태를 유지하지 않는 특성으로 인해 필요하다면 언제든 쉽게 서버 추가가 가능하기에 확장성이 높고, 서버 중 하나에 문제가 생겨도 다른 서버로 쉽게 대체가 가능하기에 견고성도 높다고 볼 수 있다.
(4) 지속 연결 프로토콜
최근 대중적으로 사용되는 HTTP 1.1 이상 버전은 지속 연결, 킵 얼라이브 keep-alive라는 기술을 제공한다. 하나의 TCP 연결 상태에서 여러 개의 요청-응답을 주고받을 수 있는 기술이다.
# HTTP 메시지 구조
HTTP 메시지는 시작 라인, 필드 라인, 메시지 본문으로 이루어져 있다. 아래와 같이 생겼는데 내용을 조금 더 자세히 보면
- 시작 라인 start line : HTTP 메시지 종류에 따라 요청/상태 라인으로 구분
>> 요청 라인 = 메서드 (공백) 요청 대상 (공백) HTTP 버전 (줄 바꿈)
- 메서드는 클라이언트가 서버의 자원인 요청 대상에 대해 수행할 작업의 종류. GET, POST, PUT 등
- 요청 대상은 HTTP 요청을 보낼 서버의 자원. 보통 쿼리가 포함된 URI 경로가 명시되고는 함
- HTTP 버전은 사용하는 HTTP 버전을 표기. HTTP/1.1과 같이 씀
>> 응답 라인 = HTTP 버전 (공백) 상태 코드 (공백) 이유 구문 (줄 바꿈)
- 상태 코드는 요청에 대한 결과를 나타내는 3자리 정수. LIKE 200, 404. 상태 코드를 통해 요청이 어떻게 처리되었는지 알 수 있음
- 이유 구문은 선택 사항으로, 상태 코드에 대한 문자열 형태의 설명임
- 필드 라인 = 헤더 라인 : 0개 이상의 HTTP 헤더가 명시되는 곳
HTTP 헤더는 HTTP 통신에 필요한 부가 정보를 의미하며,
필드 라인에 명시되는 각 HTTP 헤더는 콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성됨. 헤더 이름:헤더 값 형태
- 메시지 본문 : HTTP 요청/응답 메시지에 본문이 필요한 경우에 명시
# HTTP 메서드
메서드는 클라이언트가 서버의 자원인 요청 대상에 대해 수행할 작업의 종류라고 하는데요. 종류가 많으니 표로 정리하고 넘어갑니다.
| HTTP 메서드명 | 설명 |
| GET | 자원을 습득하기 위한 메서드로, 특정 자원을 조회할 때 사용 |
| HEAD | GET과 동일하나, 헤더만을 응답받는 메서드 |
| POST | 서버로 하여금 특정 작업을 처리하게끔 하는 메서드로, 주로 클라이언트가 서버에 새로운 자원을 생성하고자 할 때 사용 |
| PUT | 자원을 대체하기 위한 메서드 = 덮어쓰기 요청 자원이 없다면 메세지 본문으로 자원을 새롭게 생성하거나, 존재한다면 메시지 본문으로 자원을 완전히 대체함 |
| PATCH | 자원에 대한 부분적 수정을 위한 메서드 |
| DELETE | 자원을 삭제하기 위한 메서드 |
| CONNECT | 자원에 대한 양방향 연결을 시작하는 메서드 |
| OPTIONS | 사용 가능한 메서드 등 통신 옵션을 확인하는 메서드 |
| TRACE | 자원에 대한 루프백 테스트를 수행하는 메서드 |
메서드에 따라 서버가 어떻게 동작할지는 전적으로 개발자가 할 일이다. 그래서 구현하지 않는 메서드가 있을 수도 있다. '어떤 URL로 어떤 요청을 받았을 때 서버가 어떻게 동작할 것인가'는 서버 개발자들의 주된 고민 중 하나이고, 이걸 잘 정리해 둔 문서가 API 문서
# HTTP 상태 코드
상태 코드는 요청에 대한 결과를 나타내는 세 자리 정수로, 백의 자리 수를 기준으로 유형을 구분할 수 있다.
아래 표는 상태 코드 중 일부만 정리한 거다. 실제는 훨씬 많아요. (궁금하면 여기서)
알아두면 좋을 내용이라 책 내용 외에도 더 보려고 검색하다가 족장의 HTTP 상태 코드 전체 요약글도 발견했다죠.
가독성 최고,,, 다들 읽어보세요,,, 츄라이 츄라이
| 범주 | 상태코드 | 이유 구문 | 설명 |
| 100번대 (정보성 상태 코드) |
100 | Continue | 계속 진행 |
| 101 | Switching Protocols | 프로토콜 전환. HTTP 버전을 올려야 할 때 업그레이드 응답 헤더에서 사용 | |
| 102 | Processing | 처리 중이니 기달. 서버 처리에 오랜 시간이 걸릴 경우 클라이언트에서 타임 아웃이 발생하지 않도록 이 응답을 보냄 | |
| 200번대 (성공 상태 코드) |
200 | OK | 서버가 요청을 성공적으로 처리 |
| 201 | Created | 요청이 처리되어 새로운 리소스 생성 완료 | |
| 202 | Accepted | 요청 접수되었고 처리는 진행 중 | |
| 203 | Non-Authoritative Info | 응답 헤더가 오리지널 서버로부터 제공되지 않음 | |
| 204 | No Content | 요청 처리 완료, 클라이언트에게 돌려줄 콘텐츠는 없음 | |
| 205 | Reset Content | 처리 성공, 브라우저 화면 리셋해라 | |
| 300번대 (리다이렉션 상태 코드) |
300 | Multiple Choices | 선택 항목이 여러 개 있음. 서버에서 콘텐츠를 결정하지 못하고 클라이언트에게 복수 개의 링크를 응답할 때 사용 |
| 301 | Moved Permanently | 지정한 리소스가 새로운 URI로 이동. 영구적 리다이렉션. 재요청 메서드 변경 가능 응답 헤더의 Location에 이동할 곳의 새로운 URI를 기재함 |
|
| 302 | Found | 요청한 리소스를 다른 URI에서 찾음 (사용 미권장) | |
| 303 | See other | 다른 위치로 요청해라. 브라우저의 폼 요청을 POST로 처리하고, 그 결과 화면으로 리다이렉트시킬 때 자주 사용함 | |
| 304 | Not Modified | 마지막 요청 이후 요청한 페이지 수정안됨. If-Modified-Since와 같은 조건부 GET 요청에 대한 응답 | |
| 305 | Use Proxy | 지정한 리소스 액세스하려면 프록시를 통해야 함 | |
| 307 | Temporary Redirect | 임시로 리다이렉션 요청이 필요함 | |
| 308 | Permanent Redirect | 지정한 리소스가 새로운 URI로 이동. 영구적 리다이렉션. 재요청 메서드 변경되지 않음 |
|
| 400번대 (클라이언트 에러 상태 코드) |
400 | Bad Request | 요청의 구문이 잘못됨 |
| 401 | Unauthorized | 지정한 리소스에 대한 액세스 권한이 없음 | |
| 403 | Forbidden | 지정한 리소스에 대한 액세스가 금지됨. 리소스 존재 자체를 숨기고 싶으면 404로 대체함 | |
| 404 | Not Found | 지정한 리소스를 찾을 수 없음 | |
| 405 | Method Not Allowed | 요청한 URI가 지정한 메소드를 지원하지 않음. 응답헤더에 URI가 지원하는 메소드 목록을 회신 | |
| 406 | Not Acceptable | 클라이언트 Accept 헤더에 지정한 항목에 관해 처리할 수 없음 | |
| 407 | Proxy Authentication Required |
클라이언트는 프록시 서버에 인증이 필요함 | |
| 408 | Request Timeout | 요청을 기다리다 서버에서 타임아웃함 | |
| 500번대 (서버 에러 상태 코드) |
500 | Internal Server Error | 서버에 에러가 발생함 |
| 501 | Not Implemented | 요청한 URI의 메소드는 서버에 구현되어 있지 않음 | |
| 502 | Bad Gateway | 게이트웨이나 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 수신함 = 중간 서버 통신 오류 | |
| 503 | Service Unavailable | 현재 서버에서 서비스를 제공할 수 없음. 서버 과부하 또는 서비스 점검 등 일시적 상태 |
|
| 504 | Gateway Timeout | 게이트웨이나 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 응답을 기다리다 타임아웃 | |
| 505 | HTTP Ver Not Supported |
클라이언트가 요청한 HTTP를 서버가 미지원함 |
# 추가 학습 : 인증과 인가
인증 Authentication은 자신이 누구인지 증명하는 것이고, 인가(권한 부여) Authorization은 인증된 주체에게 작업을 허용하는 것을 의미한다. 적절하지 못한 접근을 차단하기 위한 방법과 규칙을 정의하는 접근통제에서 자주 나오는 개념이다. 접근통제는 식별, 인증, 인가 이렇게 3단계로 구성되어 있다. 정보보안 개념에서 살펴보자면,
| 단계 | 설명 | 접근 매체 |
| 식별 | - 본인이 누구라는 것을 시스템에 밝히는 것 - 인증 서비스에 스스로를 확인시키기 위하여 정보를 공급하는 주체의 활동 - 식별자는 각 개인의 신원을 나타내기에 사용자 책임추적성 분석에 중요한 자료 |
- 사용자 이름 - 계정명, 계정 번호 |
| 인증 | - 자신이 누구인지 증명하는 것 - 주체의 신원을 검증하기 위한 사용 증명(verify or prove) 활동 - 본인임을 주장하는 사용자가 진짜 그 사람이 맞다는 걸 시스템이 인정해주는 것 |
- 암호, PIN 번호 - 생체인증 - 토큰이나 스마트 카드 등 |
| 인가 | - 인증된 주체에게 작업을 허용하는 것 - 인증된 주체에게 접근을 허용하고 특정 업무를 수행할 권리를 부여하는 과정 - 알 필요성과 관련. 주체에게 어떤 정보가 유용할지 여부와 관계 있는 공인된 형식상의 접근수준 |
- 접근제어목록(ACL) - 보안 등급 |
🤓 (기타) HTTP의 발전사
HTTP는 초창기 HTTP/0.9를 시작으로 1.0, 1.1, 2.0을 거쳐 3.0까지 발전했다. 간단하게 공부하자면,
(HTTP/0.9) GET 메서드만 사용 가능
(HTTP/1.0) HEAD/POST 같은 다른 메서드 도입 + 헤더 지원하나, HTTP 메시지 주고받을 때마다 연결 수립 종료 반복
(HTTP/1.1) 지속 연결 공식 지원
(HTTP/2.0) 헤더 압축 및 바이너리 데이터 기반 메시지 송수신(이전에는 텍스트 기반), 서버 푸시 기능 제공 및 멀티플렉싱 기법을 활용해 HOL 블로킹 문제 완화함. 멀티플렉싱은 여러 스트림을 이용해 병렬적으로 메시지를 주고받는 기술을 의미함.
(HTTP/3.0) UDP를 기반으로 하는 QUIC 프로토콜을 활용하여 동작, 속도 개선(이전 버전은 모두 TCP 사용)
HTTP 헤더와 기반 기술(캐시, 쿠키, 콘텐츠 협상)
# 요청에 활용하는 HTTP 헤더
1) Host
요청을 보낼 호스트를 나타내는 헤더로 주로 도메인 네임으로 명시됨
2) User-Agent
웹 브라우저와 같이 HTTP 요청을 시작하는 클라이언트 측의 프로그램을 의미
웹 브라우저의 Mozilla 호환 여부, 운영체제 및 아키텍처 정보, 렌더링 엔진 관련 정보, 브라우저와 버전 정보 등이 들어감
3) Referer
클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시됨
4) Authorization
클라이언트의 인증 정보를 담는 헤더. 인증 타입과 인증을 위한 정보credentials를 차례로 명시함
예전에 공부할 때부터 웹 브라우저의 Mozilla 호환 여부가 뭔지 좀 궁금했는데, 공부하다 보니 또 나왔길래 챗지피티한테 물어봤다.
아래는 지피티가 답변해준 내용이다. 요약하자면 초기 웹 브라우저들끼리 호환하기 위해 쓰이던 문구였는데 관습적으로 이어져 내려와 지금은 "현대적인 웹 표준을 잘 지원한다"는 의미로 쓰인다 정도?
# 응답에 활용하는 HTTP 헤더
1) Server
요청을 처리하는 서버 측 소프트웨어와 관련된 정보를 명시
2) Allow
클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용됨. 상태코드 405 Method Not Allowed와 함께 사용됨
3) Retry-After
자원을 사용할 수 있는 날짜 또는 시각을 나타냄. 상태코드 503 Service Unavailable과 함께 사용됨
4) Location
클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더. 주로 리다이렉션 발생이나 새로운 자원 생성 시 사용됨
5) WWW-Authenticate
자원에 접근하기 위한 인증 방식을 설명하는 헤더. 상태코드 401 Unauthorized와 함께 사용됨
# 요청과 응답에 모두 활용하는 HTTP 헤더
1) Date
메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더
2) Connection
클라이언트의 요청과 응답 간 연결 방식을 설정하는 헤더. keep-alive, close가 가장 대표적으로 사용되는 값
3) Content-Length
본문의 바이트 단위 크기(길이)
4) Content-Type, Content-Language, Content-Encoding
전송하려는 메시지 본문의 표현 방식을 설명하는 헤더로 표현 헤더라고도 부름
순서대로 본문에 사용된 미디어 타입, 자연어, 그리고 본문을 압축하거나 변환한 방식을 명시함
# 캐시
불필요한 대역폭 낭비와 응답 지연 방지를 위해 정보의 사본을 임시로 저장하는 기술이자, 이렇게 저장된 데이터 자체를 의미한다.
캐시는 웹 브라우저에 저장(개인 전용 캐시)되거나, 클라이언트와 서버 사이에 위치한 중간 서버(공용 캐시)에 저장되기도 한다.
캐시는 사본 데이터이기 때문에, 최신 원본 데이터와 얼마나 유사한지를 확인하는 캐시 신선도cache freshness라는 개념을 사용한다.
캐시 신선도를 유지하는 가장 기본적인 방법은 캐시된 데이터에 유효 기간을 설정하는 것이다. 기간이 만료되었다면 원본 데이터를 다시 요청해야 하니 캐시 신선도를 유지할 수 있게 된다.
유효기간이 만료된 캐시의 신선도를 재검사하는 방법에는 1) 날짜를 기반으로 서버에게 물어보는 If-Modified-Since 헤더 방식과 2) 엔티티 태그(자원의 버전 식별 정보)를 기반으로 서버에게 물어보는 If-None-match 헤더 방식이 있다.
# 쿠키
서버에서 생성되어 클라이언트 측에 저장되는 데이터로, 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단이다.
쿠키는 기본적으로 <이름, 값> 쌍의 형태를 띠고 있고, 필요시 적용 범위와 만료 기간과 같은 다양한 속성을 추가할 수 있다.
서버는 쿠키를 생성해 클라이언트에게 전송하고, 클라이언트는 추후 동일한 서버에 보내는 요청 메시지에 이 쿠키를 포함하여 전송한다. 서버는 쿠키 정보를 참고해 두 개의 요청이 같은 클라이언트에서 온 것인지(세션 인증), 로그인 상태를 유지하고 있는지 등을 알 수 있게 된다.
쿠키는 정보가 쉽게 노출되거나 조작될 수 있어 보안 위험이 있다. 이를 보완하기 위해 Secure와 HttpOnly라는 속성이 있다. Secure는 HTTPS 프로토콜이 사용되는 경우에만 쿠키가 전송되도록 하는 속성이고, HttpOnly는 HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성이다. 악의적인 방식으로 쿠키를 중간에 가로채거나 위변조 할 위험이 있어, 이런 상황을 방지하기 위해 자바스크립트와 같이 다른 방식으로는 쿠키에 접근하지 못하게 하는 속성이다.
# 콘텐츠 협상과 표현
같은 URI에 대해 가장 적합한 자원의 형태를 제공하는 메커니즘을 의미한다. 같은 URI로 식별 가능한 HTML 문서라 해도, 영어로 요청하는지 한국어로 요청하는지에 따라 알맞은 형태로 제공해 주는 것이다. 지역이나 언어 설정에 따라 구글과 같은 사이트들이 다른 페이지를 보여주는 이유기도 하다. 이때 송수신 가능한 자원의 형태를 자원의 표현representation이라고 한다. 그래서 콘텐츠 협상은 클라이언트에게 가장 적합한 자원의 표현을 제공하는 메커니즘을 뜻한다.
📚 혼공단 기본 숙제
# (p271) 확인문제 1번 "도메인 네임과 네임 서버에 대한 설명으로 옳지 않은 것을 골라 보세요"
>> 답은 4번이다. www.example.com에서 루트 도메인은 com이 아니라 가장 마지막에 생략된 점(.)에 해당한다.
# (p307) 확인문제 2번 "HTTP 상태 코드에 대한 설명으로 옳지 않은 것을 골라 보세요"
>> 답은 1번이다. 300번대 상태 코드는 리다이렉션에 관련된 코드이다.
요청한 자원이 존재하지 않는, 자원을 찾을 수 없다는 응답은 404 Not Found에 더 가깝다.
📚 혼공단 추가 숙제 : HTTP 요청 메시지 확인해 보기
한빛미디어 사이트 중 하나에 들어가 보았다. 왼쪽 그림을 통해 css, js 등 페이지 접근 과정에서 주고받은 자원들의 목록이 쭉 나오는 걸 볼 수 있다. 그중 하나를 열어 더 자세히 들어가 보자. 헤더 부분을 클릭했더니 간단한 요약과 요청/응답헤더 내용을 보여준다. 아까 배운 상태 코드가 200 OK로 나오는 것도 볼 수 있고, GET 메서드를 사용해 요청한 것도 볼 수 있다. 이런 식으로 웹이 어떻게 동작하는지 살펴보는 건 사이트에 에러가 났을 때 원인 찾기에도 도움이 된다. 오래간만에 보니까 재밌고 좋네,,,
이렇게 해서 미리 하는 5주 차 예습도 마치겠읍니다.
사실 DNS며 쿠키며 개념들 다 들어는 본거잔아요.
대학 다니며 공부했는데 기억은 사라지고 단어 껍데기만 남아버렸을 뿐...
그래서 자세히 뜯어보면 사실은 모른다에 가까운 개념들을 복습도 하고
또 미처 몰랐던 세세한 부분까지 알게 된 것 같아 뿌듯하내요^^7
'공부 > IT' 카테고리의 다른 글
| [혼공단 13기/혼공네트 6주차] 실습으로 복습하는 네트워크 & 네트워크 심화 (2) | 2025.02.07 |
|---|---|
| [혼공단 13기/혼공네트 4주차] 전송 계층 (3) | 2025.02.03 |
| [혼공단 13기/혼공네트 3주차] 네트워크 계층 (8) | 2025.01.23 |
| [혼공단 13기/혼공네트 2주차] 물리 계층과 데이터 링크 계층 (5) | 2025.01.17 |
| [책 리뷰] AI 리터러시 : 인공지능 필수 지식부터 완벽 활용까지 (10) | 2025.01.13 |