네트워크 (9) 썸네일형 리스트형 캐시 리소스 파일들의 임시 저장소. 웹 브라우저가 동일한 주소로 연속으로 요청할 경우 첫 번째 요청의 결과를 로컬 PC의 캐시에 저장해둔 다음, 두 번째 요청 시 서버에 접근하는 것 대신에 로컬 PC의 캐시를 가져오는 방식. 캐시가 없으면 -데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야함->느리고 비쌈 -->캐시 적용 후 네트워크 사용량 줄일수 있고 빨라짐 캐시 시간 초과하면 1. 서버에서 기존 데이터를 변경함-다시다운로드 2. 서버에서 기존 데이터를 변경하지 않음 -최종수정일 확인으로 다시 다운로드 안해도 돼 -ETag로 Hash 생성하여 변경을 확인 할 수 있음 쿠키 Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답) Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달 HTTP는 무상태 프로토콜이다 ->클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다. 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다 클라이언트와 서버는 서로 상태를 유지하지않는다 --> 모든요청에 로그인 정보 넘기기 힘듦--->쿠키에 저장 사용처 : 사용자 로그인 세션관리, 광고 정보 트래킹 등 쿠키 정보는 항상 서버에 전송됨: 네트워크 트래픽 추가 유발, 최소한의 정보만 사용(세션id, 인증토큰), 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹스토리지) 민감한 정보는 저장하면 안됨 Set-Cookie로 .. 상태코드 1XX : 요청이 수신되어 처리중(거의 사용X) 2XX : 요청 정상 처리 200 - ok (주로 get) 201 - created 요청 성공해서 새로운 리소스가 생성됨(주로 post) 202 - accepted 요청이 접수되었으니 처리가 완료되지 않았음(요청 접수후 한시간 뒤 배치 프로세스가 요청을 처리함) 204 - no content 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 3XX : 요청완료하려면 추가행동 필요(redirection) 응답 결과에 location 헤더가 있으면 location위치로 자동 이동 300 - multiple choices 안씀... 301 - moved permanently 리소스의 uri가 영구적으로 이동, 리다이렉트시 요청 메서드.. HTTP 메서드 GET 리소스 조회 서버에 전달하고 싶은 데이터는 query를 통해 전달 POST 요청 데이터 처리, 주로 등록에 사용 메시지 바디를 통해 서버로 요청 데이터 전달 서버는 요청 데이터를 처리 - 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다. 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용 (새 리소스 생성, 요청데이터 처리-단순히 값을 변경하는 것을 넘어 프로세스의 상태가 변경되는 경우, 다른 메서드로 처리하기 어려운경우-애매하면 post) get보다 캐싱하는데 오래걸림 서버가 아직 식별하지 않은 리소스 (서버가 새로 등록된 리소스 uri를 생성해줌) PUT 리소스를 대체, 해당 리소스가 없으면 생성, 쉽게 이야기해서 덮어버림 클라이언트가 리소스 위치를 알고 uri지정.. HTTP HyoerText Transfer Protocol - HTTP 메세지에 거의 모든 형태의 테이터 전송 가능 - 서버간에 데이터를 주고 받을 때도 대부부 HTTP 사용 - TCP : HTTP/1.1,HTTP/2 - UDP : HTTP/3 - 현재 HTTP/1.1 주로 사용 특징 - 클라이언트 서버 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기 서버가 요청에 대한 겨로가를 만들어서 응답 - 무상태 프로토콜(stateless) 서버가 클라이언트의 상태를 보존X 장: 서버 확장성 높음 단: 클라이언트가 추가 데이터 전송 but 상태유지가 필요한 경우도 있음-> 로그인-> 일반적으로 쿠키,세션 이용=>최소한만 사용해야해 - 비연결성 빠른 속도로 응답 서버 자원을 효율적으로 사용할 수 있음 1시간 동안 수천.. 웹 브라우저 요청 흐름 1. DNS조회->PORT : HTTP 요청 메세지 생성 2. SOCKET 라이브러리를 통해 전달 3. TCP./IP 패킷 생성(HTTP메세지 포함) 4. 서버로 보냄 5. 서버도착 및 HTTP 응답 메세지 생성 6. 패킷생성 7. 클라이언트로 보냄 8. 클라이언트 도착 및 웹 브라우저 HTML 렌더링 URI Uniform Resource Identifier -리소스를 식별하는 통합된 방법 -locator와 name 또는 둘다 추가로 분류 될 수 있다 전체 문법 -프로토콜(https) -호스트명(www.google.com) -포트번호(443) -패스(/search) -쿼리 파라미터(q=hello&hl=ko) 좋은 URI설계 -리소스 식별에 초점을 맞춰야함 리소스랑 행위를 분리해라!=>동사는 사용하지 말자 그럼 리소스만 보고 행위는 어떻게 구분하냐? ->HTTP메서드 보고 (GET, POST,PUT,DELETE...) TCP, UDP 인터넷 프로토콜 스택의 4계층 애플리케이션 계층 (HTTP, FTP) 전송 계층 (TCP, IP) 인터넷 계층 (IP) 네트워크 인터페이스 계층 TCP특징 - 연결지향 - 3 way handshake(1.클->서 접속요청 2.서->클 접속요청,요청수락 3.클->서 접속요청 =>이 세단계가 끝나야 데이터 전송함) - 데이터 전달보증 - 순서보장 -> 신뢰할 수 있는 프로토콜 UDP특징 - 3 way handshake X - 데이터 전달보증 X - 순서보장 X => 신뢰할 수 없지만 단순하고 빠름 (IP와 거의 같다 + port + 체크섬) 이전 1 2 다음
