웹서비스 접근하기
URL과 URI
브라우저의 주소창에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타냅니다.
URL – Uniform Resource Locator는 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냅니다. URL은 scheme, hosts, url-path로 구분할 수 있습니다.
Scheme : 통신 방식 (프로토콜)을 결정합니다.
Hosts : 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타냅니다.
URI-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 파일명을 나타냅니다.
URI – Uniform Resource Identifier는 일반적으로 URL의 기본 요소인 scheme, hosts, url-path 에 더해 query, bookmark를 포함합니다.
IP Port
- 네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP Address (Internet Protocol address, IP 주소)라고 합니다. IP 주소에 진입할 수 있는 정해진 통로는 Port라고 합니다.
- 공유기를 설치하고 연결하면, PC는 IP 주소체계를 따라 네덩이의 숫자로 구분됩니다. 네덩이의 숫자로 구분된 IP 주소체계를 IPv4라고 합니다. IPv4는 각 덩어리마다 0~255까지 나타낼 수 있고 약 43 억 개의 IP 주소를 표현할 수 있음.
- IPv6는 표기법을 달리 책정하여 2^(128) 개의 IP 주소를 표현할 수 있습니다.
Port
터미널에서 리액트를 실행하면 나타나는 화면에는, 로컬 PC의 IP 주소인 127.0.0.1 뒤에 :3000과 같은 숫자가 표현됩니다. 이 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)을 의미합니다. 포트 번호는 0~ 65,535 까지 사용할 수 있습니다. 그 중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있습니다. 잘 알려진 포트 번호는 아래 와 같습니다.
22 : SSH
80 : HTTP
443 : HTTPS
추가 : https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
도메인과 DNS
Domain name : 웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소가 있습니다.
DNS : Domain Name System의 줄임말로, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템입니다. 만약 브라우저의 검색창에 naver.com을 입력한다면, 이 요청은 DNS에서 IP 주소(125.209.222.142)를 찾습니다. 그리고 이 IP 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 합니다. (모든 IP 주소가 도메인 이름을 가지는 것은 아닙니다, 도메인 이름은 일정 기간 동안 대여하여 사용합니다)
도메인의 구조 : 도메인 주소는 오른쪽부터 왼쪽으로 최상위 도메인과 여러 개의 도메인으로 구성됩니다. 여기서 탑 레벨 도메인은 .com, .kr, .net 등 도메인의 가장 오른쪽에 위치하는 도메인입니다.
4개의 DNS 서버 종류
- DNS 리커서 - 리커서는 도서관의 어딘가에서 특정한 책을 찾아달라고 요청받는 사서로 생각할 수 있습니다. DNS 리커서는 웹 브라우저 등의 애플리케이션을 통해 클라이언트 컴퓨터로부터 쿼리를 받도록 고안된 서버입니다.
- 루트 이름 서버 - 루트 서버는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 변환(확인)하는 첫 번째 단계입니다.
- TLD 이름 서버 - TLD(최상위 도메인) 서버는 도서관의 특정 책장으로 생각할 수 있습니다. 이 이름 서버는 특정 IP 주소 검색의 다음 단계이며 호스트 이름의 마지막 부분을 호스팅합니다(example.com에서 TLD 서버는 “com”입니다).
- 권한 있는 이름 서버 - 최종 이름 서버로서, 책장에 있는 사전처럼 특정 이름을 해당 정의로 변환합니다. 권한있는 이름 서버는 이름 서버 쿼리의 종착점입니다. 권한있는 이름 서버가 요청한 레코드에 대한 액세스 권한이 있다면, 요청한 호스트 이름의 IP 주소를 초기 요청을 한 DNS 리커서(사서)에게 돌려 보냅니다.
HTTP 기초
HTTP Messages
HTTP : Hypertext Transfer Protocol의 줄임말로, HTML 과 같은 문서를 전송하기 위한 Application Layer 프로토콜입니다. HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었습니다.
HTTP Messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식입니다.
요청(Requests)과 응답(Responses)은 다음과 같은 유사한 구조를 가집니다.
- start line : start line에는 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치합니다. 응답에서는 status line이라고 부릅니다.
- HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
- empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
- body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다.
이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 이야기합니다.
Start line에는 4가지 요소가 있습니다 (요청)
1. 수행할 작업 (GET, PUT , POST 등)이나 방식 (HEAD or OPTIONS)을 설명하는 HTTP method를 나타냅니다.
2. 요청 대상 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됩니다. HTTP method 마다 다릅니다.
- origin 형식 : ‘?’ 와 쿼리 문자열이 붙는 절대 경로 입니다.
- absolute 형식 : 완전한 URL 형식으로, 프록시에 연걀하는 경우 대부분 GET method와 함께 사용
- authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 authority component 입니다.
- asterisk 형식 : options 와 함께 별표 (*) 하나로 서버 전체를 표현합니다.
3. HTTP 버전에 따라 HTTP message의 구조가 달라집니다.
Headers : 헤더 이름 (대소문자 구분이 없는 문자열), 콜론(:), 값을 입력합니다.
- General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
- Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다. User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화합니다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.
- Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.
Body : HTTP messages 구조의 마지막에 위치합니다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용합니다.
- Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
- Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련이 있습니다.
응답 (status line, headers, body)
Status line : 응답의 첫 줄이며, 다음의 정보를 포함합니다.
- 현재 프로토콜의 버전(HTTP/1.1)
- 상태 코드 - 요청의 결과를 나타냅니다. (200, 302, 404 등)
- 상태 텍스트 - 상태 코드에 대한 설명
Headers : 응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있습니다.
- General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
- Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.
- Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.
Body
- Single-resource bodies(단일-리소스 본문) :
o 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.
o 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있습니다.
- Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body입니다.
Stateless : 상태를 가지지 않는다는 뜻입니다. HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않습니다. HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않습니다. 따라서, 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인할 수 있습니다.
HTTP 요청 Method :
GET : 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.
HEAD : 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.
POST : 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다
PUT : 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.
DELETE : 메서드는 특정 리소스를 삭제합니다.
CONNECT : 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.
OPTIONS : 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.
TRACE : 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.
PATCH : 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.
HTTP 상태 코드
응답은 5개의 그룹으로 나누어집니다 : 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 에러, 서버 에서.
정보 응답 : 100, 101, 102, 103
성공 응답 : 200, 201, 202, 203, 204, 205, 206, 207, 208, 226
리다이렉션 : 300, 301, 302, 303, 304, 305, 306, 307, 308
에러 응답 : 400, 401, 402, 406, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 421, 422, 423, 424, 426, 428, 429, 431, 451
서버 에러 응답 : 500, 501, 502, 503, 504, 505, 506, 507, 508, 510, 511
출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/Status
MIME 타입
클라이언트에게 전송된 문서의 다양성을 알려주기 위한 메커니즘입니다: 웹에서 파일의 확장자는 별 의미가 없습니다. 그러므로, 각 문서와 함께 올바른 MIME 타입을 전송하도록, 서버가 정확히 설정하는 것이 중요합니다. 구조는 매우 간단합니다; '/'로 구분된 두 개의 문자열인 타입과 서브타입으로 구성됩니다. 스페이스는 허용되지 않습니다.
출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types
Chrome Network Tab 사용 방법: https://youtu.be/e1gAyQuIFQo
발표
[C334] HTTP의 메소드와 CRUD(create/read/update/delete)를 적절하게 짝짓고, POST와 PUT의 차이점을 설명하세요.
Create (생성) : POST
Read (읽기) : GET
Update (갱신) : PUT 또는 PATCH
Delete (삭제) : DELETE
POST : 새로운 데이터를 계속 생성하기 때문에 요청시마다 데이터를 생성하지만
PUT : 사용자가 데이터를 지정하고 수정하는 것이기 때문에 같은 요청을 계속하더라도 데이터가 계속 생성되지는 않습니다.
안전성 차이 :
POST 방식은 서버에서 리소스의 상태를 변경할 수 있으므로 서버에 불필요한 데이터를 보내지 않는 한 서버에서 다른 데이터를 수정하거나 삭제할 수 있어 안전하지 않은 메소드입니다.
PUT 방식은 멱등성은 같은 요청을 여러 번 보내더라도 서버의 상태가 변하지 않는 속성으로 POST 보단 안전한 메소드입니다.
일관성 차이 :
POST는 서버에서 자동으로 리소스 식별자를 생성하는 데 사용됩니다, 여러 클라이언트에서 동시에 동일한 리소스를 생성할 수 있습니다.
PUT은 클라이언트에서 리소스 식별자를 명시적으로 지정해 야합니다, 그래서 여러 클라이언트가 동일한 리소스를 업데이트하지 않도록 하기 위해서 입니다.
에러 차이:
POST는 201, 200와 함께 생성된 리소스의 위치를 반환합니다.
PUT은 200 또는 204 No content와 함께 응답합니다
마지막으로 POST는 새로운 데이터를 만들어서 이전 데이터를 유지할 필요는 없지만 PUT은 데이터를 업데이트 하므로 이전 버전을 유지 해야 합니다.
출처 : https://velog.io/@yh20studio/CS-Http-Method-%EB%9E%80-GET-POST-PUT-DELETE#:~:text=%EB%B9%A0%EB%A5%BC%20%EC%88%98%20%EC%9E%88%EB%8B%A4.-,POST%20vs%20PUT,%EA%B3%84%EC%86%8D%20%EC%83%9D%EC%84%B1%EB%90%98%EC%A7%80%EB%8A%94%20%EC%95%8A%EB%8A%94%EB%8B%A4.
[C335] HTTP 응답 코드의 200, 300, 400, 500번대의 특징과 차이점을 설명하세요.
200번대 (Success) : 200 번대 응답 코드는 클라이언트의 요청이 성공적으로 처리되었음을 나타냅니다. 대표적으로 200 OK, 201 CREATED, 202 ACCEPTED 코드가 있습니다.
300번대 (Redirection) : 300 번대 응답 코드는 클라이언트의 요청을 완료하기 위해 추가 동작이 필요함을 나타냅니다. 대표적인 응답 코드는 301 Moved Permanently, 302 Found, 304 Not Modified 코드 입니다.
400번대 (Client Error) : 400 번대 응답 코드는 클라이언트 요청이 잘못되었음을 나타냅니다. 대표적인 응답 코드는 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not found 입니다.
500번대 (Server Error) : 500 번대 응답 코드는 서버 오류를 나타냅니다. 대표적인 응답 코드는 500 Internal Server Error, 501 Not Implemented, 503 Service Unavailable 입니다.
'웹서비스 개발 기초' 카테고리의 다른 글
| DevOps Day 9 (3.17) 웹서비스 개발 기초_HTTP 요청 실습 (Postman) (0) | 2023.03.17 |
|---|---|
| DevOps Day 7 (3/15) 웹서비스 개발 기초_클라이언트-서버 아키텍처 (0) | 2023.03.15 |
