웹 개발 한다는 사람이 네트워크를 모르면 안된다는 얘기를 들었다.
그래서 네트워크 관련 좋은 책이 뭐냐~ 하고 물어봤더니 이 책을 추천받았다.
'네트워크' 카테고리의 다른 글
| HTTP 메시지 (Header,Body) (0) | 2018.09.10 |
|---|---|
| REST,RESTful의 의미 (0) | 2018.08.23 |
네트워크
- 컴퓨터 네트워킹 하향식 접근 2018.10.04 30
- HTTP 메시지 (Header,Body) 2018.09.10
- REST,RESTful의 의미 2018.08.23
컴퓨터 네트워킹 하향식 접근
2018. 10. 4. 04:15
HTTP 메시지 (Header,Body)
2018. 9. 10. 11:19
HTTP 헤더의 의미에 대해 검색해서 나온 자료.
HTTP요청(Request)
헤더(Header)
요청의 HTTP 헤더는 모든 HTTP 헤더의 기본 구조를 따릅니다: 뒤에 콜론(':')이 오는 대소문자 구분없는 문자열 다음에 구조가 헤더에 종속적인 값으로 이루어집니다. 값을 포함하는 전체 헤더는 상당히 길 수도 있는 단일 줄로 구성됩니다.
많은 요청 헤더를 이용할 수 있습니다. 요청 헤더들은 몇 가지 그룹으로 나누어집니다:
Via와 같은 일반적인 헤더들은 메시지 전체에 적용됩니다.
User-Agent, Accept-Type와 같은 요청 헤더들은 (Accept-Language처럼) 좀 더 특정짓고, (Referer처럼) 컨텍스트를 제공하며, (If-None처럼) 조건에 따라 제한함으로써 요청을 수정합니다.
Content-Length와 같은 엔티티 헤더들은 요청의 본문에 적용됩니다. 요청 내에 본문이 없는 경우 말할 필요도 없이 그런 헤더 또한 전송되지 않습니다.
본문(Body)
요청의 마지막 부분은 본문입니다. 모든 요청들이 본문을 가지는 건 아닙니다: GET, HEAD, DELETE 또는 OPTIONS와 같이, 리소스를 가져오는 요청들은 일반적으로 본문을 필요로 하지 않습니다. 어떤 요청들은 리소스를 갱신하기 위한 목적으로 데이터를 전송합니다: 이것은 대게 (HTML 폼 데이터를 포함하는) POST 요청일 경우에 그렇습니다.
본문은 넓은 의미에서 두 개의 종류로 나눠집니다:
두 개의 헤더(Content-Type와 Content-Length)로 정의되는, 단일 파일을 구성하는 단일 리소스 본문.
멀티파트 본문으로 구성되는 다중 리소스 본문은 각자가 정보의 서로 다른 부분을 포함합니다. 이것은 일반적으로 HTML 폼과 연계되어 사용됩니다.
HTTP응답(Response)
헤더(Header)
응답을 위한 HTTP 헤더는 다른 헤더와 동일한 구조를 따릅니다: 뒤에 콜론(':')이 오는 대소문자를 구분하지 않는 문자열 다음에 구조가 헤더에 종속적인 값으로 이루어집니다. 값을 포함하여, 전체 헤더는 단일 줄로 표시됩니다.
이용 가능한 많은 요청 헤더들이 있습니다. 그들은 몇 가지 그룹으로 나누어질 수 있습니다:
Via와 같은 일반적인 헤더는 전체 메시지에 적용됩니다.
Vary와 Accept-Ranges와 같은 응답 헤더들은 상태 줄에서 설명하지 못했던 서버에 관한 추가적인 정보들을 제공합니다.
Content-Length와 같은 엔티티 헤더들은 요청의 본문에 적용됩니다. 요청 내에 본문이 없는 경우 말할 필요도 없이 헤더 또한 전송되지 않습니다.
본문(Body)
응답의 마지막 부분은 본문입니다. 모든 응답이 본문을 갖진 않습니다: 201 혹은 204와 같은 상태 코드를 갖는 응답에는 일반적으로 아무것도 없습니다.
본문은 넓은 의미에서 세 가지 종류로 나누어질 수 있습니다:
길이를 알고 있는 단일 파일로 구성된 단일 리소스 본문은 두 개의 헤더(Content-Type와 Content-Length)에 의해 정의됩니다.
길이를 알지 못하는 단일 파일로 구성된 단일 리소스 본문은 여러 부분으로 나누기 위해 설정된 Transfer-Encoding를 이용해 청크별로 인코딩됩니다.
멀티파트 본문으로 구성되는 다중 리소스 본문는 각자가 서로 다른 정보를 포함합니다. 이런 경우는 매우 희귀합니다.
헤더 내의 세부 항목
ㅇ 일반 헤더 (General Header) 항목
- 요청 및 응답 메세지 모두에서 사용 가능한 일반 목적의(기본적인) 헤더 항목
. Date : 메세지를 생성한 일시
.. RFC 1123에서 규정됨
.. 例) Date: Sat, 2 Oct 2018 02:00:12 GMT
. Connection : 다소 모호한 복잡성 있음
.. 클라이언트와 서버 간 연결에 대한 옵션 설정
.. 사용 형식 : Connection: `Token list`
.. 例) Connection: close => 현 HTTP 메세지 직후에 TCP 접속을 끊는다는 것을 알림
.. 例) Connection: Keep-Alive => 현 TCP 커넥션을 유지
. Cache-Control
. Pragma
. Trailer
ㅇ 엔터티/개체 헤더 (Entity Header) 항목
- HTTP 메세지 내에 포함된 선택적인 개체에 대한 구체적인 미디어 타입 등의 설명 등
- HTTP 메세지는, 이미지,비디오,오디오,HTML 문서,전자메일 등의 개체들을 실어나를 수 있음
. Content-Type : 본문 개체에 포함되는 미디어 타입 정보
.. MIME 미디어 타입 및 문자 인코딩 방식(EUC-KR,UTF-8 등)을 지정
.. 타입 및 서브타입(type/subtype) 구성
.. 타입은 9개 정도 (text,image,audio,video,application,multipart,message,
model,eample)가 표준으로 지정됨 ☞ IANA 미디어 타입 종류
.. 例) text/html; charset-latin-1 => 해당 개체가 iso-latin-1 문자집합 임
. Content-Language : 본문 개체와 가장 잘 어울리는 자연언어
. Content-Encoding : 본문 개체 데이터의 압축 방식
. Content-Length : 전달되는 본문 개체의 바이트 길이 또는 크기
.. 응답 메세지 바디의 길이(10진수)를 지정함
. Content-Location : 리소스가 실제 어디에 위치하는가를 알려줌
. Location : 리소스가 리다이렉트된 때에 이동된 주소, 또는 새로이 생성된 리소스 주소
.. 새로 생성된 경우에 HTTP 상태 코드 `201 Created`가 반환됨
.. 例) Location: http://www.ktword.co.kr/
. Allow : 해당 리소스가 지원 가능한 HTTP 메소드의 리스트를 나타냄
.. 例) Allow: GET,HEAD => 서버가 제공가능한 HTTP 메서드는 GET,HEAD 뿐임
. Expires : 리소스가 지정된 일시까지 캐시로써 유효함
. Last-Modified : 리소스를 마지막으로 갱신한 일시
. Transfer-Encoding: chuncked
.. 동적으로 생성되어 바디 길이를 모르는 경우에 조금씩 전송 가능
.. 각 chunk 마다 그 시작에 16진수 길이를 삽입하여 chunk 길이를 알려줌
참조 페이지
정보통신기술용어해설 : https://developer.mozilla.org/ko/docs/Web/HTTP/Messages
MDN- WebDocs : http://www.ktword.co.kr/abbr_view.php?m_temp1=3790
'네트워크' 카테고리의 다른 글
| 컴퓨터 네트워킹 하향식 접근 (30) | 2018.10.04 |
|---|---|
| REST,RESTful의 의미 (0) | 2018.08.23 |
REST,RESTful의 의미
2018. 8. 23. 21:31
※수업 시간에 @Controller @RestController 어노테이션에 대해 사용법을 배웠는데 의미가 궁금해서 찾아서 정리해 보았음.
REST의 의미
풀어서 쓰면 REpresentational State Transfer라고 한다.
로이 필딩이라는 사람이 2000년 박사학위 논문에 처음으로 소개했다.
WWW와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 형식 중 하나.
장비가 서로 통신하는데 CORBA, RPC, SOAP같은 방식을 원래 사용했는데, 이것이 복잡해서 간단하게 HTTP로 통신할 수 있도록 하는것이 목
적이었다.
REST는 자원지향구조(Resourece Oriented Architecture)로 웹 사이트의 이미지, 텍스트, Database 등 모든 Resource에 고유한 URI를 부여한다.
RESTful
6가지 제한 조건이 있다.
- 클라이언트 / 서버 구조
- 무상태 (Stateless)
- 캐시 처리 가능 (Cacheable)
- 계층화 체계 (Layered System)
- Code on Demand
위 6가지 조건을 준수하는 상황에서 RESTful 하다고 할 수 있다.
또한 이 상황에서 개별 컴포넌트를 자유롭게 구현할 수 있다.
조건에 대한 부분은 각각 다른 페이지에서 설명하겠다.
Web 서비스들에 적용시
REST 아키텍처 제약 조건을 준수하는 웹 서비스 API를 RESTful API라고 한다. HTTP 기반 RESTful API는 다음과 같은 측면으로 정의된다.
- 기본 URL (a base URL)
- 상태 전이 데이터 요소(a media type that defines state transition data elements) ex) Atom, microformats, application/vnd.collection+json
- 표준 HTTP 메소드 ex) OPTIONS, GET, PUT, POST, DELETE
참조 링크
'네트워크' 카테고리의 다른 글
| 컴퓨터 네트워킹 하향식 접근 (30) | 2018.10.04 |
|---|---|
| HTTP 메시지 (Header,Body) (0) | 2018.09.10 |