javaweb에 대한 필수 지식 포인트

1. WEB 애플리케이션

B/S(브라우저/서버, 브라우저/서버) 아키텍처

HTTP 전송 프로토콜(Hypertext Transfer Protocol, HTML의 이름을 기억하세요: Hypertext Markup Language)

WEB 프로그램 Tomcat/Jboss/WebLogic 등과 같은 웹 컨테이너에서 실행되어야 합니다.

2. HTTP 프로토콜

HTTP는 지원 전송 계층 프로토콜로 TCP를 사용하며 기본 포트는 80(기본 포트)입니다. .

HTTP(Hypertext Transfer Protocol)는 애플리케이션 계층 프로토콜입니다. HTTP는 요청/응답 프로토콜입니다. 즉, 클라이언트가 서버와 연결을 설정한 후 서버에 요청을 보내고, 서버가 요청을 받은 후 해당 응답 정보를 제공합니다. ,

HTTP 요청 메시지는 요청 라인, 요청 헤더, 빈 라인, 요청 본문의 네 부분으로 구성됩니다. 다음은 요청 메시지 형식에 대한 간단한 분석입니다.

요청 라인: 요청 라인은 메소드 필드와 URL 필드로 구성됩니다. . 및 HTTP 프로토콜 버전 필드는 공백으로 구분된 세 부분으로 구성됩니다. 일반적으로 사용되는 HTTP 요청 방법은 GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE, CONNECT입니다.

GET: 클라이언트가 서버에서 리소스를 읽으려면 GET 방법을 사용하세요. GET 방식은 서버가 URL에 있는 리소스를 응답 메시지의 데이터 부분에 넣어 클라이언트로 다시 보내도록 요구합니다. 즉, 서버에 리소스를 요청하는 것입니다. GET 메소드를 사용하는 경우 요청 매개변수와 해당 값이 URL에 추가됩니다. 물음표("?")는 URL의 끝과 전달된 요청 매개변수의 시작을 나타내는 데 사용됩니다. 매개변수가 제한되어 있습니다. 예를 들어 /index.jsp?id=100&op=bind입니다.

POST: POST 메소드는 양식 데이터 제출을 완료하고 처리를 위해 데이터를 서버에 제출하는 등 클라이언트가 서버에 많은 정보를 제공할 때 사용할 수 있습니다. GET은 일반적으로 리소스 정보를 얻거나 쿼리하는 데 사용되며 POST는 사용자 데이터와 함께 제공되며 일반적으로 리소스 정보를 업데이트하는 데 사용됩니다. POST 메소드는 요청 매개변수를 HTTP 요청 데이터에 캡슐화하여 이름/값 형태로 나타나며, 이는 대량의 데이터를 전송할 수 있습니다. 요청 헤더: 요청 헤더는 한 줄에 한 쌍씩, 키워드로 구성됩니다. 및 값은 영문 콜론 ":"으로 구분하여 사용됩니다.

요청 헤더는 클라이언트의 요청에 대해 서버에 알립니다. 일반적인 요청 헤더는 다음과 같습니다.

User-Agent: 요청을 생성한 브라우저 유형

Accept: 클라이언트가 인식하는 응답 콘텐츠 유형 목록 별표 "*"는 범위별로 유형을 그룹화하는 데 사용됩니다. "*/*"를 사용하면 모든 유형이 허용됨을 나타내고, "type/*"를 사용하면 유형 유형의 모든 하위 유형이 허용됨을 나타냅니다.

수락 -Language: 클라이언트가 허용하는 자연어

Accept-Encoding: 클라이언트가 허용하는 인코딩 압축 형식

Accept-Charset: 허용되는 응답 문자 집합

Host: 요청된 호스트 이름, 여러 개 허용 도메인 이름이 동일한 IP 주소, 즉 가상 호스트에 있습니다.

연결: 연결 방법(닫기 또는 연결 유지)

쿠키: 클라이언트 확장 필드에 저장되며 이 도메인에 속한 쿠키를 서버로 보냅니다.

빈 줄: 마지막 요청 헤더 뒤에 빈 줄이 있으며, 아래에 더 이상 요청 헤더가 없음을 서버에 알리기 위해 캐리지 리턴 및 줄 바꿈 문자가 전송됩니다. body: 요청 패키지 Body는 GET 방식에서는 사용되지 않고, POST 방식에서는 사용됩니다. POST 방법은 고객이 양식을 작성해야 하는 상황에 적합합니다. 요청 패키지 본문과 관련하여 가장 일반적으로 사용되는 것은 패키지 본문 유형 Content-Type과 패키지 본문 길이 Content-Length입니다.

다음은 응답 메시지 형식에 대한 간단한 분석입니다.

상태 줄: 상태 줄은 HTTP 프로토콜 버전 필드, 상태 코드 및 상태 코드 설명 텍스트의 세 부분으로 구성됩니다. ; 상태 코드는 세 자리로 구성됩니다. 첫 번째 숫자는 다음과 같이 5가지 일반적인 상태 코드 범주를 나타냅니다.

1xx: 서버가 클라이언트 요청을 수신했음을 나타냅니다.

2xx: 서버가 요청을 성공적으로 수신하고 처리했음을 나타냅니다.

3xx: 서버가 클라이언트의 리디렉션을 요구함을 나타냅니다.

4xx: 클라이언트의 요청에 불법적인 콘텐츠가 있음을 나타냅니다.

5xx: 서버가 클라이언트 요청을 정상적으로 처리하지 못했음을 나타냅니다. 요청 중에 예기치 않은 오류가 발생했습니다.

상태 코드 설명 텍스트에는 다음 값이 있습니다.

200 OK: 클라이언트 요청이 성공했음을 나타냅니다.

400 잘못된 요청: 클라이언트 요청에 구문 오류가 있어 서버에서 이해할 수 없음을 나타냅니다.

401 인증되지 않음: 요청이 승인되지 않았음을 나타냅니다. 이 상태 코드는 WWW-Authenticate 헤더 필드와 함께 사용해야 합니다.

403 금지됨: 서버가 요청을 받았지만 서비스 제공을 거부했음을 나타내며 일반적으로 서비스 이유가 제공됩니다.

404 찾을 수 없음: 요청한 리소스가 존재하지 않습니다. , 잘못된 URL이 입력되었습니다.

500 내부 서버 오류: 서버에 예상치 못한 오류가 발생하여 클라이언트의 요청을 완료할 수 없음을 나타냅니다.

503 서비스를 사용할 수 없음: 서버가 현재 서버를 처리할 수 없음을 나타냅니다. 클라이언트의 요청에 따라 일정 시간이 지나면 서버가 정상으로 돌아올 수 있습니다.

3.Servlet

Servlet은 간단히 말해서 javaWEB으로 작성된 서버측 프로그램입니다. 자바. 사용자가 동적 요청(정적 요청은 HTML에 대한 직접적인 요청)을 하면 실제로는 서블릿을 요청하는 것입니다

WEB 컨테이너는 서블릿을 메모리에 로드하고 init 메소드를 통해 초기화합니다#🎜🎜 #

Service() 메소드는 요청 메소드에 따라 해당 처리 메소드 doPost() 또는 doGet()을 호출합니다. 다른 요청 메소드 doPut() doOptions()도 있지만 이러한 메소드는 일반적으로 사용되지 않습니다. 보안 관점에서 사용되며 권장됩니다.

서버에 더 이상 서블릿이 필요하지 않으면(일반적으로 서버가 종료될 때) 서버는 서블릿의 destroy() 메소드를 호출합니다.

4. JSP

Java Server Pages는 정적 인코딩 시스템과 동적 인코딩의 하이브리드입니다. Java It HTML에는 Java 코드가 내장되어 있다고도 합니다. JSP 이전에는 상대적으로 강력한 기능과 고급 디자인을 갖춘 Servlet을 본체로 사용했지만 HTML 페이지는 완전히 Java의 out.print()를 사용하여 한 줄씩 작성되었습니다. 출력이 페이지 작성 및 수정에 매우 불편하여 SUN이 JSP를 출시하게 되었습니다. ASP 및 PHP와 같은 JSP는 모두 내장 언어입니다. 또한 WEB 컨테이너가 이동되면 JSP가 Servlet으로 컴파일됩니다. JSP는 Servlet의 업그레이드 버전이라고도 합니다. Java WEB 컨테이너는 많이 있습니다. 여기서는 Tomcat을 예로 들어 보겠습니다. 앞서 언급했듯이 WEB 프로그램은 WEB 컨테이너에서 실행되어야 합니다. Tomcat은 Java WEB 프로그램을 실행하기 위한 WEB 컨테이너로 사용됩니다. Tomcat은 JAVA 언어로 작성되었으며 실행 환경으로 JVM이 필요합니다. #… 🎜#

conf………………………. 구성 파일 webx.ml server.xml 등

lib… ...Tomcat을 실행하는 데 필요한 jar 패키지logs………………………….로그 파일temp… … ……….임시파일

webapps………………WEB 프로그램(컴파일된 프로젝트 파일)

work…………생성 이 디렉토리에 있는 jsp 파일의 java 파일

보완적으로 Tomcat은 jsp 파일을 실시간으로 Java 파일로 컴파일하지 않기 때문에 때때로 페이지가 수정되어 시간 내에 적용되지 않습니다. 이번에는 작업 디렉터리에서 해당 파일만 삭제하면 됩니다.

6. Java WEB 프로젝트 구조

일반적으로 우리가 자주 이야기하는 Java 프로젝트는 기본적으로 모두 WEB 프로젝트(B/S 아키텍처)입니다. Java가 C/S 프로그램을 수행할 수 없다는 의미는 아닙니다. 실제로 Java의 Swing은 인터페이스 그리기에 가장 널리 사용되는 언어가 되었습니다. 빠르고 간단하기 때문에 C/S 프로그램을 개발하기 위해 Java를 사용하는 사람들이 점점 더 줄어들고 있습니다. 우리는 주로 Java WEB 프로젝트에 대해 이야기합니다. 다음은 가장 기본적인 프로젝트 구조입니다.

src…………………….JAVA 소스 코드, Java 파일 디렉터리

webContent/webRoot… 🎜🎜#WEB-INF

lib……………………………. 프로젝트에 필요한 jar 패키지

web.xml… … ………… WEB 프로그램 입구 위 내용은 Java WEB 프로젝트의 핵심 구조입니다. 실제 개발에서는 특히 프레임워크를 참조한 후에 프로젝트를 구축하는 것이 이보다 더 복잡합니다. , 구성 파일의 증가로 인해 일부 새 디렉터리가 추가됩니다.

7. 개발 프레임워크

앞서 언급했듯이 클라이언트가 동적 요청을 시작하면 요청은 전체 요청 처리 작업은 Servlet에서 처리되며, 다른 요청이 필요할 때마다 Servlet이 작성됩니다. 모듈의 경우 많은 부분이 서블릿으로 작성되어야 하며, 요청의 반환을 수정하려면 이를 달성하기 위해 Java 코드(서블릿)도 수정해야 합니다.

이는 기능 확장 및 유지 관리에 더욱 번거로움이 있어 Java WEB 개발의 주류인 Webwork, Struts, SpringMVC, Jfinal 등 많은 통합 개발 프레임워크의 인기를 촉진했습니다. 뼈대.

프레임워크를 사용하면 개발 프로세스 속도를 높일 수 있다는 매우 일반적인 개요가 있습니다. 유사한 프로젝트에서 코드를 재사용하면 개발자가 사전 구축된 프레임워크를 통해 많은 시간과 노력을 절약할 수 있습니다. 지루한 코딩 작업을 수행하기 위한 것입니다. 사용자는 핵심사업 개발에만 신경쓰게 하고, 프레임워크는 원천기술 및 사업개발과 무관한 다양한 기술적인 문제를 보호하는데 도움을 줍니다. 하지만 프레임워크를 더 깊이 이해하고 더 능숙하게 사용하려면 기본 원칙을 이해하고 그 소스인 서블릿을 찾아야 합니다.

작동 원리를 간략하게 설명하기 위해 SpringMVC를 예로 들어보자.

SprfngMVC는 주로 DispatcherServlet(서블릿 디스패처, web_xml에 구성됨)을 통해 구현됩니다. 서블릿 인터페이스는 프런트엔드 컨트롤러라고도 하며 프런트엔드의 요청이 여기에 먼저 도착하며 백그라운드에서 적절한 핸들러를 일치시키는 역할을 합니다. DispatcherServlet의 주요 작업 흐름은 다음과 같습니다.

1. 클라이언트는 웹 서버에 http 요청을 보내고 웹 서버는 http 요청을 구문 분석하여 DispatcherServlet의 요청 매핑 경로(web.xml에 지정됨)와 일치하면 웹 컨테이너가 요청을 전송합니다. DispatcherServlet.#🎜🎜 #

2. 이 요청을 받은 후 DipatcherServlet은 요청 정보(URL, Http 메소드, 요청 헤더 및 요청 매개변수 Cookie 포함)를 기반으로 요청을 처리하는 프로세서 컨트롤러(Handler)를 찾습니다. 등) 및 HandlerMapping 구성.

3. DispatclierServlet은 HandlerMapping에 따라 해당 Handler를 찾고 처리 능력을 Handler에 전달한 다음(Handler는 특정 처리를 캡슐화함) 특정 HandlerAdapter가 Handler에 특정 호출을 수행합니다.

5. Handler는 데이터 처리를 완료한 후 ModeAndView 객체를 DispatcherServlet에 반환합니다.

6. Handler가 반환한 ModelAndView는 논리적 뷰일 뿐입니다. Di spatcherSevlet은 ViewResolver를 통해 초대 뷰를 실제 뷰로 변환합니다(이 문장은 단순히 반환할 페이지의 상대 경로를 반환하고 try 구문 분석기를 통해 특정 페이지로 변환합니다).

7. Dispatcher는 모델을 통해 ModeAndView의 매개변수를 구문 분석하고 최종적으로 전체 보기를 표시하고 클라이언트에 반환합니다.

8. SpringMVC를 사용하여 기능 모듈 작성

프레임워크 구성 작업량이 상대적으로 크기 때문에 다양한 기술에 대한 이해도 필요하므로 설명하지 않겠습니다. 당분간.

이 실제 개발에서 기존 프레임워크를 기반으로 기능 모듈을 완성하고 기능의 기본 프로세스를 이해하는 방법에 대해 간략하게 이야기하겠습니다. 로그인을 예로 들어

1 , 먼저 로그인 입구(JSP 페이지)가 있어야 합니다. SpringMVC 프레임워크에서는 JSP 페이지에 직접 액세스하는 것을 권장하지 않으므로 로그인 페이지에 대한 액세스도 백그라운드를 통해 처리됩니다. . Write丨ogin.jsp 페이지 및 로그인 반환 페이지 index.jsp;

3. preLogin()과 doLogin()이라는 두 개의 요청 제어 메서드가 포함된 LoginController를 작성합니다. 로그인 페이지에 대한 요청 처리(login.jsp로 반환)를 담당하며 doLogin()은 로그인 요청을 처리하고 index.jsp로 반환합니다.

4. 로그인 요청은 login.jsp의 양식이나 ajax를 통해 이루어져야 합니다.

Request/preLogin 비즈니스 로직 처리는 login.jsp로 반환 à 사용자 이름과 비밀번호 입력...

Request/doLogin 비즈니스 로직 처리는 로그인 결과 index.jsp를 반환 .

9. 기타 기본 지식

데이터베이스 작업, Jdbc/Hibernate/Mybatis# 🎜🎜#JSP 태그, EL 표현식, Struts 태그, C 태그 등

기본 프론트엔드 기술 CSS/JS/jQuery/Ajax

위 내용은 javaweb에 대한 필수 지식 포인트의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!