It's pretty well explained in this blog post how it works. In essence, if you can construct such a URL query to split individual parts of a subsequent SQL query in more query parameters (thus the fragmentation part of it's name), the WAF (Web Application Firewall) might have problems determining it's supposed to drop the request, or whatever it's setup to do when such an attempt is detected.
One way of exploiting this is by a adding a begin comment
/* at the end of one input parameter, and end comment
*/ at the beginning of the next one. WAF will consider the two parameters as acceptable, if it's not looking at the whole picture (what SQL syntax comes out as the product of all input parameters).
This might result in a part of SQL code between the two input parameters to be ignored by the RDBMS's SQL engine. If the ignored (commented out) part happens to be filtering SQL query results (say,
... WHERE user=$param1 and start_date>=$param2... can then result in
... WHERE user=$param1/* and start_date>=*/$param2..., providing for a vector to exploit possible $param1 values WAF will consider as acceptable, and also ignore other filters up till the point where $param2 value is used), the end product of such an exploit can disclose information the developers never intended to be disclosed.
HPP attacks, on the other hand, are trying to take advantage of differences between the interpretation of input parameters by WAF and the request handling web application, when a single parameter name is repeated many times. For example, let's consider this URL query to be parsed and analyzed by both:
?q=acceptable+request&q=not+acceptable+request. WAF might take the first input parameter as the one to analyze and ignore the next one, while web application might do exactly the opposite.
Note that I'm only using URLs as an example, and the input parameters can be requested at any other part of a HTTP request headers (cookies, POST or GET request fields,...), depending on where they're later parsed from by web application.