HTTP는 웹클라이언트가 서버와 대화하는 방법과 서버에서 다시 클라이언트로 데이터가 전송되는 방법을 정의한 표준이다.
HTTP는 일반적으로 HTML파일과 그 안에 포함된 이미지를 전송하는 수단쯤으로 생각되지만, HTTP는 데이터 형식을 가리지 않고전송이 가능하다.
HTTP는 웹 브라우저와 웹 서버 사이에 통신을 위한 표준 프로토콜이다.
HTML 연결(클라이언트의 서버로의 요청)
- 클라이언트가 서버의 HTTP 기본 포트 80에 대해 TCP 연결을 연다. 다른 포트 사용시 URL에 명시
- 클라이언트가 특정 경로에 위치한 리소스를 요청하는 메시지를 서버로 보낸다. 요청에는 헤더와 선택적으로 빈 줄로 구분된데이터가 포함된다.
- 서버는 클라이언트에게 응답을 보낸다. 응답은 응답 코드로 시작하며, 메타데이터의 전체 헤더와 빈 줄 그리고 요청된 문서 또는 에러 메시지가 뒤따라온다.
- 연결을 종료한다.
요청본문.
- 헤더
기본적으로 클라이언트에서 요청시 첫 줄에
전송방식 파일위치 클라이언트가 지원하는 프로토콜 버전이다.
Ex) GET /index.html HTTP/1.1
- 추가적인 정보가 필요할 때는 키워드: value 식으로 전송한다.
Keyword: value
-> 키워드는 대소문자를 가리지 않는다. 그러나 값은 경우에 따라 대소문자를 가리기도 한다.
-> 헤더의 각줄은 캐리지리턴과 라인피드의 쌍으로 끝난다.
- 마지막 줄
마지막줄에 사용되는 키워드 Accept는 클라이언트가 처리 할 수 있는 데이터의 타입을 알려준다.(서버에서 무조건 참고하는것은 아니다.)
EX) Accept: text/html, text/plain, image/gif, image/jpeg
MIME
MIME타입은 두 레벨로 구분된다(타입, 서브타입)
->타입은 매우 일반적인 데이터의 종류(그림인지 텍스트인지)
->서브타입은 구체적인 데이터의 타입을 나타낸다.(GIF이미지, JPEG 이미지, TIFF 이미지)
타입은 총 8가지가 있다.
Text/* 사람이 읽을 수 있는 문자 타입
images/* 그림 타입
Model/* VRML 파일과 같은 3D모델 타입
Audio/* 소리 타입
Video/* 소리를 포함할 수 있는 움직이는 그림 타입
Application/* 바이너리 데이터 타입
Message/* 이메일 메시지와 HTTP 응답과 같은 프로토콜에 따른 엔벨로프 타입
Multipart/* 다수의 문서와 리소스의 컨테이너 타입
서버에서 오는 응답
서버에서 첫 번째 줄은 프로톨콜과 응답 코드를 나타낸다. 200 OK는 가장 일반적으로 성공했다는 의미이다.
100~199까지는 항상 정보를 제공하는 용도로 사용되고, 200에서 299까지는 항상 성공을 의미한다. 그리고 300~399까지는 항상 전송방향을바꾸는 용도로 사용되고, 400~499까지는 항상 클라이언트의 요청에러가 나타난다. 마지막으로 500~599까지는 서버 에러이다.
Ex) HTTP/1.1 200 OK
추가적인 헤더는 응답이 만들어진 서버 기준의 시간, 서버 소프트웨어, 전송 종료 후 연결의 상태, MIME 미디어 타입, 전송된 문서의 크기를 보내준다.
Keep-Alive
HTTP 1.0은 요청마다 새로운 연결을 연다.
실제로, 일반적인 하나의 웹 세션에서 모든 연결을 열고 닫는데 엄청난 시간이 들고 https의 경우 SSL이나 TLS를 사용하는 암호화된연결의 경우 일반 소켓 보다 더 많은 작업을 필요로 한다.
HTTP1.1에서는 한번열린 소켓을 닫지 않는다.
클라이언트는 HTTP 요청 헤더의 Connection 필드의 값을 Keep-Alive로 설정하여 소켓을 재 사용할 것임을 표시한다.
Connection:Keep-Alive
URL 클래스는 명시적으로 해제하지 않는 한 투명하게 HTTP 연결 유지(Keep-Alive) 기능을 지원한다. 즉, URL 클래스는 서버가 해당 연결을 종료하기 전에 같은 서버에 다시 연결할 경우 소켓을 재사용한다.
HTTP 메소드
HTTP 서버와의 통신은 요청-응답 패턴을 따른다.
각각의 HTTP 요청은 다음 둘 또는 세 요소로 구성된다.
-> 첫 번째 줄은 HTTP 메소드와 메소드가 실행될 리소스의 경로를 포함하고 있다.
-> 이름-값 필드로 구성된 헤더는 인증 자격과 선호하는 데이터 타입과 같은 메타정보를 제공한다.
-> 요청 본문은 요청된 리소스의 실제 데이터를 포함하고 있다.(POST, PUT에 한정)
HTTP 메소드에는 아래와 같은 4가지 주요 메소드가 있다.
-> GET, POST, PUT, DELETE
4개의 메소드는 모두 일정의 규칙을 가지고 있어, 아무때나 사용할 수 있는 것은 아니다.
- GET메소드
-> GET 메소드는 요청한 리소스를 읽어 들인다. GET메소드는 요청에 실패해도 추가적인 부작용이 발생하지 않기 때문에 반복적으로 보내도 된다. GET은 미리 요청을 할 수 있어 필요한 페이지를 미리 로드 요청할 수 있다.
- PUT 메소드
-> PUT 메소드는 URL에 명시된 서버로 리소스를 업로드 한다. PUT 메소드는 부작용에서 자유롭지 않지 않지만, 실패 여부에 상관없이 반복 요청이 가능하다.
- DELETE 메소드
-> 지정된 URL의 리소스를 삭제한다. 이 메소드 역시 부작용으로 부터 자유롭지는 않지만, 삭제 요청의 성공 여부가 확실하지 않을경우 요청을 다시 보내기만 하면 된다. (반복 요청이 가능)
- POST 메소드
-> URL에 명시된 서버로 리소스를 업로드 하지만, 새로 업로드된 리소스로 서버가 해야할 일을 명시하지 않는다. 서버는 업로드된리소스에 대해 해당 URL로 반드시 접근 가능하도록 만들어야 하는 것은 아니다. 대신 다른 URL로 이동시키거나, 완전히 다른 리소스의 상태를 변경하는데 업로드된 리소스를 사용할 수도 있다. POST는 구매하기와 같이 반복 요청에 대해 안전하지 않는 동작에 사용해야한다.
각 메소드들의 차이점
-> GET 요청은 URL 안에 필요한 모든 정보를 포함하고 있기 때문에, 미리 로드가 가능하다. 그리고 변화를 일으키지 않는 동작을 수행한다.
-> 다른 3가지 메소드들은 북마크하거나 링크를 만드는 등에 동작에 사용할 수 없으며, 변화를 일으키는 동작을 수행한다.
Ex0 쇼핑카트에 아이템 추가는 서버에 변경 요청을 하지 않기에 GET으로 보낸다. 그러나 주문을 할 때는 변경 요청이 발생하므로POST로 보내야하 한다.
데이터를 전송할때 Header에 두 개의 필드는 필수이다.
Content-length 필드는 본문의 바이트 수를 명시.
Content-type 필드는 바이트의 MIME 미디어 타입을 명시한다.
쿠키
많은 웹 사이트는 연결들 사이에서 지속적인 클라이언트 측의 상태를 저장하기 위해 쿠키라는 알려진 텍스트의 작은 문자열을 사용한다.
쿠키는 서버에서 클라이언트로 전달되고 HTTP 요청과 응답의 헤더를 통해 다시 전달된다.
-> 쿠키는 세션 ID, 쇼핑 카트, 로그인 자격 정보, 사용자 설정과 같은 것들을 표시하기 위해 서버에 의해 사용된다.
-> 서버는 클라이언트의 부라우저에 쿠키를 설정하기 위해 HTTP 헤더에 Set-Cookie 헤더를 포함시킨다.
Ex) Set-Cookie: cart=ATVPDKIKX0DER
서버는 하나 이상의 쿠키를 설정할 수 있다.
쿠키는 이름=값을 지정하는 쌍 이외에도 유효기간, 경로 도메인, 포트, 버전 그리고 보안옵션과 같은 쿠키 자신의 범위를 제어하는 다양한 속성을 가질 수 있다.
쿠키는 비밀번호와 같은 민감 정보를 가질 수 있기네 secure라는 보안 속석을 설정해야한다.
Set-Cookie: key=etrogl7*;Domain=.foo.example.com; secure
브라우저는 이와 같은 쿠키에 대해 안전하지 않은 채널로 전송되지 않게 해야한다.
XSRF와 같이 쿠키를 훔치는 공격에 대응하기 위해, 쿠키에 HttpOnly 속성을 설 정할 수 있다.
-> 이 속성은 브라우저에게 HTTP와 HTTPS를 통해서만 쿠키 값을 반환하도록 말한다. 특히 JavaScript에서 접근하지 못하도록 한다.
Set-Cookie: key=etrogl7*;Domain=.foo.example.com; secure; Httponly
'JAVA > 자바 네트워크 프로그래밍' 카테고리의 다른 글
sha 256 다이제스트 생성(Thread) (0) | 2016.12.24 |
---|---|
Runnable을 사용한 MD5 다이제스트 생성방법 (0) | 2016.12.24 |
소켓 통신 (어플리케이션) (0) | 2016.12.24 |
UDP 통신 (0) | 2016.12.24 |
Java 소켓 통신(서버) (0) | 2016.12.24 |