일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
- 협업프로젝트
- couchcoding
- 바깥쪽 여백
- 클라이언트와 서버 구조
- HTML
- margin
- HTTP 메시지 바디
- IP
- Content
- CSS
- 박스모델
- 무상태
- 선택자
- 요청 헤더
- border
- 6주포트폴리오
- HTTP 메시지
- 프로토콜
- URL
- 클라이언트
- 경계선
- 응답 헤더
- padding
- connectionless
- 서버
- 팀프로젝트
- HTTP
- 카우치코딩
- 안쪽 여백
- 콘텐츠 영역
- Today
- Total
목록HTTP (8)
정리하고 기록하며 성장하는
요구사항 회원 정보 관리 API 만들기 회원 목록 조회 회원 조회 회원 등록 회원 수정 회원 삭제 API URL 설계 URL (Uniform Resource Identifier) 회원 목록 조회 - /read-member-list 회원 조회 - /read-member-by-id 회원 등록 - /create-member 회원 수정 - /update-member 회원 삭제 - /delete-member 이렇게 설계 하는 것이 좋은 URI 설계 일까? 리소스를 식별하는 것이 좋은 URI 설계 이다 리소스 - 개념 자체를 의미한다 예) 미네랄을 캐라 -> 미네랄이 리소스이다 회원을 조회 하라 -> 회원이 리소스이다 리소스를 어떻게 식별하는것이 좋을까? 회원을 등록 , 수정 , 조회 하는 행위에 해당하는 것을 모..
HTTP 메시지 구조 start-line 시작 라인 header 헤더 empty line 공백 라인 (CRLF) message body HTTP 요청 메시지 http 요청 메시지도 본문에 필요한 body 부분을 가질수 있다 GET /search?q=hollo&hl=ko HTTP/1.1 HOST:www.google.com 요청 메시지 - HTTP 메서드 start-line = request-line(요청) 과 status-line(응답)이 있다 request-line method SP(공백) request-target SP (요청하는 대상) HTTP-version CRLF(엔터) 종류 : GET , POST , PUT , DELETE 서버가 수행해야 할 동작 지정 GET : 리소스 조회 POST : 요청 ..
TCP/IP 프로토콜 연결을 유지하는 모델이다 클라이언트1 과 서버의 요청 응답이 끝나고 다른 클라이언트가 서버에게 요청을 보내더라도 클라이언트1과 서버의 연결은 끊어지지 않은 상태이다 연결을 유지하지 않는 모델 (비연결성) 자원을 서버와 클라이언트가 요청과 응답을 받을 동안에만 유지를 하고 아닐때는 끊어버린다 최소한의 자원으로 서버를 유지할 수 있게 된다 즉 , 클라이언트1과 서버의 요청과 응답이 끊어지면 TCT/IP 프로토콜의 연결이 종료된다 HTTP 기본적으로 연결을 유지하지 않는 모델이다 일반적으로 초 단위 이하의 빠른 속도로 응답을 보낸다 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적다 비연결성을 사용했을 떄 장점 서버 자원을 매우 효율적으로..
무상태 프로토콜 스테이스리스 (Stateless) 서버가 클라이언트의 상태를 보존하지 않는다 클라이언트가 요청할 때부터 필요한 데이터를 그떄그떄 담아서 넘겨준다 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다 응답 서버를 쉽게 바꿀수 있다 (무한한 서버 증설 가능) 서버는 상태를 보관하지 않는다 스케일 아웃 - 수평 확장에 유리하다 한계 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다 더보기 무상태 - 로그인이 필요 없는 단순한 서비스 소개 화면 상태 유지 - 로그인 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지시켜야 한다 일반적으로 브라우저 쿠키와 서버 세션등을 사용하여 상태를 유지 시킨다 상태유지는 최소한만 사용한다 꼭 필요한 경우에만 어쩔수 없이 사용해야..
클라이언트와 서버 구조 Request Response 구조 클라이언트는 서버에 요청을 보내고 응답을 대기한다 서버가 요청에 대한 결과를 만들어서 응답해준다 클라이언트와 서버를 분리했을 때 장점 비즈니스로직과 데이터는 서버가 담당한다 클라이언트는 UI 와 사용성에 집중한다 클라이언트와 서버가 각각 독립적으로 진화할 수 있다 클라이언트가 요청을 보내면 서버가 기다렸다가 응답을 받은 후 요청에 대한 결과를 만들어서 응답해 준다
HTTP (HyperText Transfer Protocol) html을 전송하는 프로토콜 모든 것은 HTTP 프로토콜에 담아서 전송한다 이미지 , 음성, 영상 , 파일 , JSON, XML (API) 거의 모든 형태의 데이터가 전송 가능하다 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다 HTTP/1.1 가장 중요한 버전 기반 프로토콜 HTTP/1.1 , HTTP/2는 TCP 프로토콜 위에서 동작한다 HTTP/3는 UDP 기반으로 개발되어 있다 성능 최적화가 되어 있다 HTTP 특징 클라이언트 서버 구조 무상태 프로토콜 (stateless) , 비연결성 HTTP 메시지 단순함 , 확장 가능
URI 리소스를 식별하는 통합적인 방법 즉 , 자원자체를 식별하는 방법을 의미한다 URL 리소스가 있는 위치를 지정 URN 리소스에 이름을 부여 URL 분석 https://www.google.com/search?q=hello&hl=ko url 전체 문법 scheme://[userinfo@]host[:port][/path][?query][#fragment] ://:@:/?# schema : 주로 프로토콜이 사용된다 프로토콜 : 클라이언트와 서버간 약속 규칙 어떤 방식으로 자원에 접근할 것인가 http : 80 포트를 기본으로 쓴다 https : 443 포트를 주로 사용한다 http 나 https를 쓰면 포트는 생략이 가능하다 지금은 대부분의 웹사이트 들이 https 프로토콜을 사용한다 호스트명 : 도메인명..

인터넷에서 서버와 클라이언트는 어떻게 통신할까? 서버: 네트워크에 연결된 컴퓨터들 중 서비스를 제공하는 쪽 클라이언트: 네트워크에 연결된 컴퓨터들 중 서비스를 받는 쪽 IP 주소의 등장 배경 서버와 클라이언트는 인터넷 망을 통해 통신하는 데 인터넷 망이 복잡하다 복잡한 인터넷 망에 규칙을 부여해 놓은 것이 IP 주소 이다 IP(Internet Protocol) 주소는 32비트 숫자로 구성되 있다 사람이 알아볼 수 있게 네 개의 8비트 숫자로 마침표로 구분하여 표시한다 클라이언트 와 서버 각각 IP 주소가 있어야 서로 통신할 수 있다 IP 주소를 사용하는 목적 지정된 IP 주소로 데이터를 주고받기 위해 사용한다 데이터를 주고 받을때 패킷(Packet)이란느 작은 단위로 분할 한 후 조고받는다 패킷은 자신이..