네트워크 상에서 호스트를 특정 지을 수 있는 주소 - MAC 주소 : 사람을 식별하는 고유한 주민등록번호 - IP 주소 : 주소 : 모든 IP/MAC 주소를 알고 있기란 어렵다 -> DNS를 이용 + IP 주소는 언제든 변경될 수 있다 / 임의로 지정이 가능하다.
DNS - 전화번호부(개인소유, 공용)와 유사한 기능을 수행! - 개인 소유 / 공용 모두 가능하다. - 사람이 기억하기 쉬운 도메인 이름과 호스트를 특정지을 주소를 매핑 * 도메인: 호스트에 부여되는 문자열 이름 (e.g. google.co.kr)
- hosts 파일 – 개인 전화번호부 : 모든 전화번호를 관리하기 어렵다
DNS 서버는 계층적 도메인 구조를 띄고있다. - 가장 위에 있는 도메인 서버 : root 도메인 서버
- root - 가장 위에 있는 도메인 서버 : 전세계 10개정도 존재 - 루트 네임 서버 - TLD (Top-Level-Domain) : 원래 최상위 도메인 서버 ( .com, .org, .net , .int , .edu, .gov, .mil 등) - Second Level Domain : co, ac - Third Level Domain : google , naver 등등 - Forth Level Domain : www, api, blog 등등
서브 도메인 (하위 도메인) - 도메인의 일부인 도메인 - naver.com -> maps.naver.com - wikipedia.com -> en.wikipedia.com / ko .wikipedia.com
각 도메인을 담당하는 도메인 서버 - ROOT 네임 서버 - TLD 서버 - Authoritative DNS 서버: 찾고자 하는 도메인의 IP주소를 저장하는 최종 서버 - local DNS 서버: 클라이언트가 가장 먼저 찾는 DNS 서버 (DNS Resolver)
질의 - 반복적 질의 - local DNS 서버에서 root DNS 서버에 묻고, 다시 TLD에 묻고, 다시 다음 서버에 묻고, 그럼 최종적으로 얻을 수 있음 - 반복적으로 계속 질문하는 것 - 재귀적 질의 - root DNS 서버에 묻고 응답받고, root가 TLD에게 묻고 계속가서 원하는 서버가 도달할때까지 물어서 최종으로 가져다줌
DNS 레코드 (자원 레코드) - DNS 서버에 저장하고 있는 것
- DNS 레코드 타입 - A 레코드: 도메인에 대한 IPv4 주소 - AAAA 레코드: 도메인에 대한 IPv6 주소 - CNAME 레코드: 도메인에 대한 별칭 - NS 레코드: 네임 서버 주소 - SOA 레코드: 도메인에 대한 관리자 정보
DNS 캐시 : TTL 기간동안 DNS 저장
자원과 자원의 식별
네트워크 상에서의 ‘자원’ - 네트워크로 주고받을 수 있는 모든 정보 - 파일, 이미지, 동영상, HTML, XML, JSON, ...
네트워크 상에서의 ‘자원’이 필요하다면 자원을 요청해야 함 : 일상적으로 이루어지는 일 - 자원을 요청하고 요청한 자원을 응답하려면 자원을 식별(identify)할 수 있어야 == 자원의 식별자(identifier)가 있어야
자원의 식별자 == URI (Uniform Resource Identifier) URI는 자원을 식별할 수 있는 문자열
- URI의 분류 -URI는 위치 혹은 이름으로 분류 가능하다 - URL: 위치 기반 자원 식별(Locator) - URN: 이름 기반 자원 식별(Name)
- URL 구성 요소 - scheme - 일반적으로 프로토콜 이름 명시 : https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml - (예시) ftp://ftp.kernel.org/ , https://example.com/ - authority = [ userinfo "@" ] host [ ":" port ] - 사용자 이름을 이용한 인증 가능 – 생략 가능 - 호스트 이름 (도메인 이름 혹은 IP 주소) - 포트 번호 – 생략 가능 - path - 자원이 있는 경로 - query - key:value형태로 서버에 전달할 문자 형태의 파라미터 - ?로 시작, & (혹은 ;)로 다수의 query 구분 - fragment - 자원의 조각(fragment)를 가리키는 데에 사용 (#로 구분) - 예를 들면 북마크 / 서버에 전달되는 정보는 아님
서버(server)-클라이언트(client)의 개념 - 서버는 대답하는 대상(response) - 클라이언트는 요청하는 대상(request)
서버가 응답해야 하는 자원 -정적인 자원 :언제/어디서/누가 봐도변하지 않는 정보(e.g. HTML, 이미지, 동영상, ...) -동적인 자원 :언제/어디서/누가 보는지에 따라변할 수 있는 정보(매일의 기온, 아이디에 따른 이름) -> 여기서 주로 사용되는 것이 데이터베이스
웹과 관련된 서버 - 웹 서버 - 정적인 자원에 응답 -NGINX , APACHE, Microsoft IIS, - 웹 어플리케이션 서버 (WAS) - 동적인 자원에 응답 - Apache Tomcat, JBoss, IBM webSphere - 둘의 차이는 응답해야하는 자원의 차이
- 웹 서비스에 웹서버와 웹 어플리케이션 서버를 동시에 한다. : 동적인 자원은 웹서버, 동적인 자료만 웹 어플리케이션의 서버에 해서 과도한 부하 방지 - 웹 서버에서 보안을 하면 웹 어플리케이션 서버도 안전 : 보안상의 이점 - 여러 웹 어플리케이션 서버 연동 용이(확장성 유리) : 여러 웹 어플리케이션과 웹 서버가 연동 가능하다.
HTTP
현재 HTTP의 기본 특성 (***반드시 기억하기***) - 요청-응답 기반 클라이언트-서버 구조 프로토콜 - HTTP 클라이언트 (HTTP 요청 메세지) - HTTP 서버 (HTTP 응답 메세지) * 오해 방지: 서버 간에도 HTTP 메세지(모든종류의 메세지를 주고 받을 수 있음)를 주고받을 수 있음
-미디어-독립적프로토콜 - 어떤 형태의 데이터도 HTTP 메세지로 보낼 수 있음 ( HTML, 이미지, JSON, XML, 파일, 영상, 이미지 등 )
-비연결성프로토콜 - HTTP 1.0, HTTP 1.1, HTTP 2.0은 TCP 기반 - 연결성 프로토콜이라면 다수의 클라이언트가 연결을 시도할 경우 : 연결을 유지하는 동안 서버의 자원 소모가 너무 크다! - TCP는 연결성 프로토콜 But, HTTP는 비연결성 프로토콜
-스테이트리스프로토콜 - 서버는 클라이언트의 상태를 기억하지 않는다 - 클라이언트는 한 서버에 종속될 필요가 없어짐 - 여러 번 요청을 보내야 할 경우 여러 서버에 요청할 수 있음 서버의 확장이 용이해진다 - 왜 스테이트리스 프로토콜일까? (만일 스테이트풀 프로토콜이면 : 클라이언트는 한 서버에 종속/ 여러 요청을 보내야 할 경우 한 서버에만 요청해야 함 -> 서버의 IP가 바뀐다면? 요청을 보낸 서버에 장애가 생긴다면? 서버가 여러 대 있다면? 통신이 불가능해짐)
-지속 연결프로토콜 - 하나의 연결을 사용해 여러 개의 HTTP 요청/응답 주고받기 (만일 연결할 때마다 3-way handshake를 하면, 혼잡 증가, 시간 지연 증가(handshake, slow start 시간))
HTTP 버전별 특성 : 지금까지 지속적으로 개발이 되기에 여러 버전이 있음 - HTTP 0.9: 단일한 요청 방법(GET 메서드), 비지속 연결, 별다른 기능 X - HTTP 1.0: 다양한 요청 방법과 헤더 추가 - HTTP 1.1: 지속 연결 기능 추가 - HTTP 2.0: 요청 순서대로 응답을 반환할 필요 없음, 헤더 압축 - HTTP 3.0: UDP 기반 프로토콜인 QUIC로 변경
HTTP 메세지
HTTP 요청 헤더 – Start line - HTTP 메서드 (공백) /요청 대상 (공백) HTTP /버전 (개행)
- 여기서 GET이 메서드, restapi이 요청대상, 버전은 1.1 - HTTP 메서드 (***반드시 기억하기***) - GET : 자원 조회 (”갖다 줘”) - 리소스 조회에 사용 - 일반적으로 쿼리(&) 문자열을 사용하되, 본문은 없음 - POST : 요청할 데이터 처리 (“이 데이터 처리해 줘”) - 메세지 본문으로 처리할 데이터 - 메세지 본문에 해당하는 데이터 처리하도록 요청 - 어떻게 처리할지는 서버가 결정 (e.g. 새 자원 생성, 가공) - PUT : 자원 덮어쓰기 ( “이 자원으로 대체해줘”) - 자원이 있다면 본문으로 보낸 데이터로 대체 - 자원이 없다면 본문으로 보낸 데이터로 생성 - PATCH : 자원 부분 변경 - DELETE : 자원 삭제 * 이외에도 HEAD, OPTIONS, TRACE, CONNECT - HTTP 메서드 : https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
- 멱등성: 여러 번 동일한 요청을 보내도 첫 요청 결과와 같은가 - 캐시(응답결과를 조금 저장해놓은것) 가능성: 응답 결과를 캐시해서 사용할 수 있는가
요청 대상 : 요청할 자원의 위치
HTTP 버전 : HTTP 1.1, HTTP 2.0
HTTP 응답 헤더 – Start line - HTTP 버전 (공백) 응답 코드(공백) 이유 문구 (개행)
- 응답 코드 -2XX: 성공 - 200 OK: 요청 성공 (GET) - 201 Created: 요청 성공, 새로운 자원 생성됨 (POST) - 202 Accepted: 요청 성공, 처리는 아직 미완료 - 204 No Content: 요청 성공, 응답할 데이터 없음 - 3XX: 리다이렉션 - 응답의 Location 헤더를 통해 특정 위치로 이동 - 이 요청을 처리하려면 추가적인 처리가 필요함 - 4XX: 클라이언트 오류 : 니 책임이야! 라는 말! - 401 Unauthorized: 미인증 - 403 Forbidden: 금지된 자원에 접근 (자원에 접근할 권한이 없음) - 404 Not Found: 요청한 자원 없음 (공개한 자원이 아님) - 5XX: 서버 오류 : 내 책임이다. - 500 Internal Server Error: 서버 오류 - 503 Service Unavailable: 현재 이용 가능하지 않음
- HTTP 헤더 표기 - header-field = field name ":" field-value - 메세지 전송에 필요한 부가 정보
- 대표적인 헤더 정보 - Host: 요청 호스트에 대한 호스트명 + 포트 정보 - Date: 메세지 생성 시간 - Referer: 직전에 머물렀던 URL - User-Agent: 클라이언트가 사용한 소프트웨어 및 브라우저 명칭과 정보 - 특정상황에 디버깅할 때, 특정상황을 알아낼 수 있음 - 참고자료 : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent - Server: 서버 소프트웨어 명칭과 정보 - Connection: keep-alive일 경우 킵 얼라이브 - Location: 리다이렉트시 이동할 경로 - Content-Type: HTTP 요청 및 응답에서 사용될 컨텐츠의 유형 - MIME 타입으로 명시 - 웹 상에서 컨텐츠의 유형을 나타내기 위한 방법 ( 형식으로 표기, *은 ‘모든’을 의미) 일종의 웹 상에서 확장자를 나타내기 위한 방법! - 일반 MIME 타입 :https://developer.mozilla.org/ko/docs/Web/HTTP/MIME_types/Common_types - text/html; charset=utf-8: HTML 문서, 인코딩 형식은 utf-8 - application/json: JSON 형식 데이터, API Request-Reseponse에서 주로 사용 - image/png: png 타입 이미지 데이터 - text/plain; charset=utf-8: 텍스트 파일 데이터, 인코딩 형식은 utf-8 - application/xml: xml 데이터 - Content-Encoding: 데이터의 인코딩/압축 방식 - gzip: gzip 압축 (가장 대중적) - deflate: deflate 압축 - br: brotli 압축 - identity: 압축하지 않음 - Content-Length: 데이터의 바이트 단위 길이 - Content-Language: 데이터의 언어 - en:일반적 영어, en-US: 미국이라는 국가의 영어 - ko:일반적 한국어, ko-KR: 한국이라는 국가의 한국어
네트워크에서의 캐시란? - 서버의 지연을 줄이기 위해 웹 페이지, 이미지 등의 자원 사본을 임시 저장하는 웹 기술 - HTTP는 상태를 유지하지 않는다 : 그렇다면 자원을 요청할 때마다 자원은 새롭게 응답될까? : 캐쉬가 없다면 이렇게 됨
- 캐시된 자원이 저장되는 공간: 클라이언트(브라우저) 혹은 특별한 서버(캐시 서버, 프록시 서버)
cache-control 헤더 - 관련 자료 : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control - cache-control 헤더로 캐시 기능을 알림 - cache-control: max-age=숫자(초) 캐시한 자원의 지속 시간 - cache-control: no-cache 캐시 가능한 자원이나, 항상 origin 서버에 검증하기 : 본서버에 검증하고 써라!!! - cache-control: no-store 캐시하면 안될 자원
캐시된 자원에는 유효 기간이 있음 - 해당 자원이 언제 마지막으로 변경되었는지를 알리는 Last-Modified 헤더
캐시된 자원의 변경 - 방법 1. - 클라이언트는 요청시 if-modified-since 헤더로 특정 시점 이후 자원 변경 여부를 묻는다 - 만일 변경되었다면 다시 다운로드 - 만일 변경되지 않았다면 서버는 304 Not Modified 응답을 보낸다 -> "자원 변경 안됐으니까, 캐시로 Redirect 해라"
- 방법 2. - Etag를 통해 자원의 변경 여부 감지 가능 - 서버는 캐시된 자원에 Etag라는 식별 문자를 붙이고 - 클라이언트는 If-None-Match 헤더를 통해 해당 Etag가 변경되었는지를 물어본다
예시 - 초기 응답: Etag 값은 abc123 - 재요청: Etag 값이 여전히 abc123인지 확인 -재응답(변경되지 않은 경우): 304
쿠키
쿠키(cookie) - 서버로부터 받은 정보를 클라이언트 측(웹 브라우저)에 임시 저장되는 이름=값 형태의 데이터 - HTTP는 상태를 유지하지 않는 프로토콜이라 요청을 보낼 때마다 불러와야할 수도 있음. -> 이것의 방지를 위해 임시저장 - 유효 기간이 있음 - 쿠키를 전송할 도메인과 경로가 정해져 있음
- 서버는 클라리언트를 식별할 수 있는 세션 ID를 제공하고, - 클라이언트는 서버에게 세션 ID를 (쿠키로) 넘겨 호스트를 식별하게 할 수 있다 : 쿠키에 민감한 정보를 세션ID라는 특별한 정보로 바꾸어서 보냄 : 그럼 쿠키는 민감한 정보가 없이, 세션 아이디만 가짐 -> 쿠키는 민감한 정보를 알 수 없음. 민감한 정보는 서버에서만!! 볼 수 있음 = 보안이 상승
쿠키(cookie)의 보안 기능 - Secure : HTTPS인 경우에만 전송 - HTTPS ; S는 암호화한다는 의미! - HTTPOnly : 자바스크립트에서 접근 불가 (document.cookie) - XSS 공격 방지
컨텐츠 협상
- 예시 : 위키피디아 등에서 영어로 들어가도 한국어를 제안해줌
컨텐츠 협상 (Content negotiation) - 클라이언트가 원하는 컨텐츠를 받을 수 있도록 서버에게 부탁하는 기능 - 컨텐츠 타입, 언어, 인코딩 방법 등 클라이언트 맞춤 컨텐츠 제공 기능 - Accept(-X) 헤더 이용 - Accept: 클라이언트가 선호하는 컨텐츠 타입 - Accept-Encoding: 클라이언트가 선호하는 인코딩 - Accept-Language: 클라이언트가 선호하는 언어
- 여러 맞춤 요청을 보낼 수 있음 - 여러 맞춤 요청을 보낼 때 Quality Value 값을 기준으로 우선순위를 매길 수 있음 - <= Quality Value(q) <= 1 (클수록 우선순위가 높음) - Accept: text/html, text/plain;q=0.9, text/*;q=0.8, */*;q=0.7 - Accept-Language: ko-KR,ko;q=0.9, en-US;q=0.8, en;q=0.7 (한국어 가장 높은 우선수위, 그 다음 미국영어, 그다음영어)
